Due to a recent hack of my servers I am in some kind of ultimate restriction taste and thus wanted to limit the permissions of all the root folders like so:
chmod o-x /*
To enable login for other users again, I do:
chmod o+x /home
Now, I have another user which is not root and which should be the only one allowed to login, but it cant - the SSH authentication itself works but then this error appears:
/bin/sh: Permission denied
Seems easy to grant permissions to the bin folder like so:
chmod o+x /bin
But I still get the same Permission denied message.
Whats going on here?
The execute bit (x) on directories allows an user to go into that directory. If you remove the x bit from the root directory (/), then it is not possible to go into that directory and get the details of its contents. But in order to get the details of the bin directory under the / directory, that is necessary.
The same is true for /home and what is in it, by the way.
You might argue that you can do an ls / and list it's contents. That is because the contents itself are in the inode of the listed folder. But try to get a detailed listing with ls -l / and you will see that the permissions can not be listed. This is because the permissions are in the inode of the bin directory, but without the x permission, you are not allowed to enter the root directory in order to look at that inode.
Removing the x permission bits from the root directory is going to cause lots of problems. Don't do it! Better to learn concepts like SELinux or similar.
Related
I need some help about permissions on Linux. I know having world writable file can be dangerous and many people recommend to not have world writable file.
In order to "protect" my Linux, i searched for every world writable file using find / -perm -0002 -type f. Thanks to this command, I found a world writable file under my /root/a_directory/. As my /root directory is 700, other user cant edit the world writable file.
So my question is, what is the risk if I have world writable file under a directory which can't be access by other users ?
Am i safe if /directory1/world_writable_file.sh is 777 and /directory1/ is 700. Is there no risk with this situation ?
Directory permissions behave quite differently from file permissions.
Since the directory doesn't allow other (non-root and non-group) users any operation (read/write/execute) on the directory, they can't even enumerate the files inside this directory, so they sure can't access them.
Here is a practical example:
user#host$ sudo su
root#host$ mkdir testdir
root#host$ printf '#!/bin/bash\necho test" > testdir/testfile
root#host$ chmod 0777 testdir/testfile
root#host$ chmod 0700 testdir
root#host$ exit
user#host$ ./testdir/testfile
-bash: ./testdir/testfile: Permission denied
user#host$ ls testdir
ls: cannot open directory 'testdir': Permission denied
However, this is NOT a good practice in handling sensitive files.
It is very easy to misconfigure file permissions, so you should never rely on having a secure directory.
If someone accidentally changes the directory's permission to 0701 (others can execute), which seems like a fairly negligible change, everyone will be able to execute, read and write any file with 0777 permissions if they know its exact path.
Moreover, the scenario you described can happen only if:
A. The permissions on the directory are changed after the files are already there. In this case, you should simply use chmod -R o-rwx to remove permissions for other users.
B. The directory owner created the file after the directory was already configured, and then added permissions using chmod o+wx or something similar. Since new files created in a directory with 0700 permissions mask, have a default mask of 0644, and the only user that can access the directory is the owner, there is no other way. In this case, simply refrain from doing so.
Anyway, if you are interested in reading and understanding more about UIDs in Unix systems in general and Linux in specific, I wrote a comprehensive guide on the subject.
I would like to know what is the best, correct and recommended way of doing chown and chmod to website files and folders.
I recently started working on linux and I have been doing it in the site root directory like the following:
sudo chown www-data:www-data -R ./
sudo chmod 775 -R ./
I know it is not the best way. There is a protected folder which should not be accessible with browsers and should not be writable, so I did the following to protected folder:
sudo chown root:root -R protected/
sudo chmod 755 -R protected/
Is it correct? If anything can be improved please let me know.
Read your command again. What you are saying is "make everything executable" below these directories. Does an HTML or gif to be executable? I don't think so.
Regarding a directory which should not be writable by the webserver. Think of what you want to do. You want to revoke the right to write a directory from the webserver and the webserver group (and everybody else anyway). So it would translate to chmod -w theDir. What you did is to tell the system "I want root to make changes to that directory which shall be readable by everybody and the root group". I highly doubt that.
So I would suggest having the directory owned by a webserver user with only minimal read access, it should belong to a group (of users, that is) which is allowed to do the necessary of the modification. The webserver does not belong to that group, as you want the outside world to be prevented from making modifications. Another option would be to hand over all the directories to root and to the editor group and modify what the webserver can do via the "others" permission group. But what to use heavily depends on your environment.
Edit:
In general, the "least rights" policy is considered good practice: give away as few rights as possible to get the job done. This means read access to static files and depending on your environment php files, read and execute rights for cgi executables and read and execute rights for directories. Execute rights for directories allow you to enter and read it. No directory in the document root should be writable by the webserver ever. It is a security risk, even though some developers of bigger CMS do not seem to care to much about that. For temporary folders I would set the user and groups to nobody:nogroup and set the sticky bit for both user and groups.
This is the second time i've had this occur to me.
I am working on a rails app, and I create a file via touch show.html.haml, and I can do an ls and see the file.
but I am using both WinSCP and SFTP for sublime, and neither can see this file!
WinSCP returns...
and Sublime returns,
Downloading folder "/app/qa/www/htdocs/qa-dashboard/app/views/scripts/" ... 1 file to download
yet it never downloads the file. What is happening here? I've also verified that it wasn't the touch command. i've tried vi'ing the file, and saving it. Same thing.
I've also verified that the hosts are matching.
Additional notes:
I am using elevated_user to create the file, and user, ddavison to edit the file. ddavison is not in the group.
File modes are,
drwxrw-rw- ... .
drwxr-xrwx ... ..
-rw-rw-rw- ... show.html.haml
The permissions on your scripts directory appear to be incorrect:
drwxrw-rw- ... .
^--^-- missing eXecute bit
The execute bit on directories allows the directory's contents to be listed. Since the "group" and "other" perms on the scripts directory do not allow listing, you'll get that error. Most like you're logged in to the shell as the owner of the directory, so you can get listings all you want, but you're logging in as a user OTHER than the owner via winscp, so they're unable to list the directory contents.
I expect the problem is with the permissions on the containing directory -
drwxrw-rw- ... .
Both of those programs probably try to chdir into that directory before retrieving the file. In order to do so, the directory must have x (execute) permissions for the user they are logging in as. Based on what you said, it seems that set 'other' needs +x -
chmod o+x /app/qa/www/htdocs/qa-dashboard/app/views/scripts/
Depending on the users/groups in question, you may want to consider removing write permission -
chmod o-w /app/qa/www/htdocs/qa-dashboard/app/views/scripts/
For directories, the x permission bit isn't execute, rather it's "list the contents of this directory". Since the directory's permissions are only 'rwxrw-rw-', only the owner may list the contents of the directory. Provide "other" that permission using chmod o+x /app/qa/www/htdocs/qa-dashboard/app/views/scripts.
When cding into one of my directories called openfire the following error is returned:
bash: cd: openfire: Permission denied
Is there any way around this?
#user812954's answer was quite helpful, except I had to do this this in two steps:
sudo su
cd directory
Then, to exit out of "super user" mode, just type exit.
Enter super user mode, and cd into the directory that you are not permissioned to go into. Sudo requires administrator password.
sudo su
cd directory
If it is a directory you own, grant yourself access to it:
chmod u+rx,go-w openfire
That grants you permission to use the directory and the files in it (x) and to list the files that are in it (r); it also denies group and others write permission on the directory, which is usually correct (though sometimes you may want to allow group to create files in your directory - but consider using the sticky bit on the directory if you do).
If it is someone else's directory, you'll probably need some help from the owner to change the permissions so that you can access it (or you'll need help from root to change the permissions for you).
chmod +x openfire worked for me. It adds execution permission to the openfire folder.
Alternatively, you can do:
sudo -s
cd directory
You've got several options:
Use a different user account, one with execute permissions on that directory.
Change the permissions on the directory to allow your user account execute permissions.
Either use chmod(1) to change the permissions or
Use the setfacl(1) command to add an access control list entry for your user account. (This also requires mounting the filesystem with the acl option; see mount(8) and fstab(5) for details on the mount parameter.)
It's impossible to suggest the correct approach without knowing more about the problem; why are the directory permissions set the way they are? Why do you need access to that directory?
I know this post is old, but what i had to do in the case of the above answers on Linux machine was:
sudo chmod +x directory
Unless you have sudo permissions to change it or its in your own usergroup/account you will not be able to get into it.
Check out man chmod in the terminal for more information about changing permissions of a directory.
I have been reading about Security of Design. I noticed a tip of lowest permission level. So I did the above code to my junk files. Unfortunately, the junk-folder seemed to contain some server files. A few sites become forbidden. The folder contained stuff such as "Mail", "dev" and "Public". The reason for junking them was that they are empty.
The files are located in a server of a CS-dept. There is no special CMS or anything like that. Before running 'chmod 644 some_files', I am promth to ask your opinion.
Why did the sites become forbidden? What are the lowest permission levels?
Lowest possible permission level is of course 000. But that wouldn't make much sense.
600 rw------- for private files
700 rwx------ for private directories
711 rwx--x--x for directories with public files, but without permission to list dir
644 rw-r--r-- for publicly readable files
755 rwxr-xr-x for publicly readable dirs
The web server usually runs as a different userid from "real" users. So you make it so that a "real" users files aren't readable by anybody else, and the web server can't read them. That's why 744 is a better permission set for files the web server needs to see.
Most likely the owner of the folders that are forbidden is another than the ones that are available. The user that runs the file or it's group must have read (and sometimes executable) permissions on the files/folder. Since you removed the read, write and executable privileges on the group and the world no one but the owner of the files will be able to run them.
TLDR:
Wrong owner of file/folder. chown to correct user.
Your problem: your user account does not have execute permissions for the rest of the world.
Solution:
You need to put the permissions 701 for your user folder. You can also set them to 711.
It is the folder which contains your public_html etc.
Then, check that your public_html has the permissions 755. Similarly, the contents should also be 755 in public_html.