Linux File Permissions

When I first started out with Linux permissions were sorta hard to grasp, most likely because I never took the time to really sit down and understand them, but also because they are quite different than Windows permissions.

In Windows you can really put some detail in the ACLs, but with Linux you either need ACLs implemented or you need to understand how file permissions work. So first off, lets use the following example

# ls -l /
drwxr-xr-x  13 root root  4096 Apr 27  2007 usr
drwxr-xr-x  20 root root  4096 Oct  3 00:33 var

As you can see these are both owned by user root and group root and that the user has read, write, and execute permission permissions, while the group and others do not. So lets make a change to that to better explain permissions. So lets say we created /home/johndoe/usr and /home/johndoe/var.

# ls -l /home/johndoe/
drwxrwxr-x  13 johndoe johndoe  4096 Apr 27  2007 usr
drwxr-xr-x  20 johndoe johndoe  4096 Oct  3 00:33 var

Again, only the owner himself could write to the directories in the previous example. In this one we ran ‘chmod 775 usr’, which now gives anyone in johndoe group access to write to that folder. So say I come along and need to write to that folder, the sysadmin can run the following:

# groups manis
manis : manis
# usermod -G johndoe manis
# groups manis
manis : manis johndoe

Now the user manis can write to that directory. It might not be a good idea to place the user manis in the primary group of johndoe and the reason is that if by default directories and files are created with write permission manis would be able to write to all of those. Instead it might be better to have them both belong to a separate group, maybe empl or students or a department name. Then permissions can be given to a specific group, but they will not default to permissions that are less than desirable.

That really sort of sums it up for controlling access to files, the standard flags are r=read, w=write, x=execute. You will also sometimes run across a couple more.

The first is the sticky bit, which Linux ignores on files, but for directories it prevents users other than the owner from renaming, moving, or deleting files within the directory. The sticky bit is represented by a ‘t’ or a ‘T’ in place of the ‘x’ in permissions. The capital T means that the file/directory in question did not have ‘x’ set for the ‘others’ bits.

# ls -l ~
-rw-rw-r-x 1 user user      111 Aug 29 20:26 test.txt
# chmod 1664 test.txt
-rw-rw-r-T 1 user user      111 Aug 29 20:26 test.txt
# chmod 1665 test.txt
-rw-rw-r-t 1 user user      111 Aug 29 20:26 test.txt
# chmod 0665 test.txt
-rw-rw-r-x 1 user user      111 Aug 29 20:26 test.txt

As you can see we started out with a normal file, we ran chmod with a preceding 1, which sets the sticky bit. We removed executable permissions by making it 664 instead of 655 and you see there is a capital T replacing the ‘x’ in the others column. If we add executable rights to ‘others’, that then becomes a lowercase ‘t’. Remove the one and we now are back to where we started. Again, Linux ignores sticky bits on files, I was just using a file as an example.

Setuid and setgid, like the sticky bit, are seen less often than r,w,x permissions. What this does is fairly simple, when the bit is set the file is run as the user or group that owns the file. An example is /usr/bin/passwd.

# ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 30796 Feb  7  2008 /usr/bin/passwd
# ls -l /etc/passwd
-rw-r--r-- 1 root root 1428 Aug 26 09:52 /etc/passwd

The ’s’ in the owners column means that the setuid bit has been set. As you can see /etc/passwd can only be written to by root, but users need to be able to change their password. So when /usr/bin/passwd is executed it is view by the system as being run by root, and therefore any files owned by root that passwd interacts with can be modified by users allowed to execute the file. The same with setgid, the ’s’ is in the group column, but it will take on the role of that group. To set the setuid bit, you would make the first bit of chmod a 4 and for setgid you would use a 2.

# chmod 4755 testfile.txt
# ls -l testfile.txt
-rwsr-xr-x  1 manis  eng  0 Nov 24 15:47 testfile.txt
# chmod 755 testfile.txt
# ls -l testfile.txt
-rwxr-xr-x  1 manis  eng  0 Nov 24 15:47 testfile.txt
# chmod 2755 testfile.txt
# ls -l testfile.txt
-rwxr-sr-x  1 manis  eng  0 Nov 24 15:47 testfile.txt

The last thing I want to talk about is using changing permissions. There are 3 main programs, chmod, chgrp, and chown. I have seen some variation to just to be safe I will say to check the usage before changing permissions. My examples will be for CentOS.

chmod

All of my examples used numbers to represent the permissions, but you can use the letters too. If you wanted to give write permission to just a group you would run.

# chown g+w testfile.txt

and to a user

# chown u+w testfile.txt

For a lot of people I think the octal numbers for chmod can be a little confusing at first. It is really just simple math that will eventually become second nature. A 4 is equal to read permissions, a 2 is equal to write permissions and a 1 is equal to execute permissions. There are two things about these numbers, one is that they follow the binary count right to left. When running ‘ls -l’ permissions are displayed RWX or 421 and binary is 16 8 4 2 1. The other thing is that no matter how you spin it the combination of numbers is unique for any combination of permissions, which I will show you in a minute.

Anyway back to the math of it. When you run chmod in most cases you just use 3 digits, like in one of my examples 755. The first is for the owner, the second is for the group, and the third is everyone else. The number 7 comes from 4, read access, 2, write access, and 1, execute permissions. The next number 5, is read access (4) and execute (1) or (4+1) and the same goes for the “other” permissions. Read+write is 6, execute would be just 1, read would be just 4, so if you think about it you could do any combination and it would represent a unique set of permissions. 600 would be read and write for the owner, but nothing for anyone else.

The best thing you can do is just create some files and start playing with permissions. Soon enough you will know them like the back of your hand and know how to change them to fit your needs.

If I jumped around too much or made something unclear please comment and I will try to clarify.

You can leave a response, or trackback from your own site.