|
Resources for Linux Programmers
Trials, Software, Downloads, and More.
File permissions are those letters you see at the beginning of ls -loutput:
$ ls -l
drwxrwxrwx 1 reegen reegen 4096 Jan 22 10:05 dropbox
drwx------ 1 reegen reegen 4096 Dec 6 8:50 private_logs
-rw-r--r-- 1 reegen reegen 9663 Oct 8 16:03 public
-rw------- 1 reegen reegen 8925 Jan 12 11:17 secret
The first part of the output has 10 characters, which can be broken up as follows (excuse the ASCII art....)
d rwx rwx rwx
| | | |
| | | \-> "Other" permissions
| | |
| | \-> "Group" permissions
| |
| \-> "User" permissions
|
\-> Type of file
The first character says what kind of file this is. (d==directory, l==symlink, p==pipe, s==socket, etc). The next three groups define the permissions of this file. An "r" means "allow read access", a "w" means "allow write access", and "x" means "allow execute access.
On a normal file ("-" in the type-of-file field) "read" and "write" are pretty self explanatory. "Execute" means that this file can be executed as a program. So if the file were a shell script or valid compiled executable (ELF format, etc) named program_name, you could run ./program_name or, if this directory were in your path, just program_name. Without the execute bit, you'd need to type sh program_name for a shell script, perl program_name for a perl script, etc.
The kernel decides if you have read/write/execute access based on these rwxbits. Say you want to read a file -- what logic does the kernel use to decide if you should be granted read access? Test your intuition with the following examples:
$ id
uid=1000(doug) gid=1000(doug) groups=1000(doug),1001(web)
$ ls -l foo.html
-rw-r----- 1 www-data web 9663 Oct 8 16:03 foo.html
Following this logic, we'd all agree that doug can read this file, because he's part of the group web, which has read access. However how about this situation:
$ id
uid=1000(doug) gid=1000(doug) groups=1000(doug),1001(web)
$ ls -l bar.html
-rw----r-- 1 www-data web 19838 Sep 17 4:22 bar.html
Most people's intuition would say sure, doug can read this file, since the read bit is set for other. This is not the case!
Standard file permissions come in three flavours: user, group, and other. Many people think that if any option is satisfied, then access is granted. In reality, the kernel checks only the most appropriate - it does not "check all of them, falling through when a particular test fails"!
So, to be explicit, here is how you can think of the file permission logic, using read access as an example:
- If the user is the owner of the file, see if the owner read bit (400) is set. If not, tough luck. Do no other tests.
- If the user is a member of the group that owns the file see if the group read bit (040) is set. If not, tough luck. Do no other tests.
- If the user is not the owner of the file nor a member of the group that owns the file, see if the other read bit (004) is set. If not, tough luck. Do no other tests.
The distinction is an important one. You could create a file that you own that is readable by group and other, but not by you. Yes, this seems somewhat counterintuitive.
We are frequently put in a position where we want to give only certain users access to a directory or files. We put them in a special group, and tailor the group permissions of the files/directories to allow them this special access. Say we wanted to have the compiler only available to developers, we may do the following:
# ls -l /usr/bin/gcc
-rwxr-xr-x 1 root root 74088 Sep 23 15:13 /usr/bin/gcc
# addgroup devel
# chgrp devel /usr/bin/gcc
# ls -l /usr/bin/gcc
-rwxr-xr-x 1 root devel 74088 Sep 23 15:13 /usr/bin/gcc
# chmod o-rx /usr/bin/gcc
# ls -l /usr/bin/gcc
-rwxr-x--- 1 root devel 74088 Sep 23 15:13 /usr/bin/gcc
About the Author:
Brian Hatch is the author of Hacking Linux Exposed, Building Linux VPNs, and the weekly Linux Security: Tips, Tricks, and Hackery newsletter.
In addition, he's the co-maintainer of the secure SSL wrapper Stunnel, a frequent lecturer, security BOFH, and has this thing called a "Day Job" where he masquerades as Chief Hacker at security consultancy Onsight, Inc.
His root password is a 823 digit prime.
|
