I understand that with Unix file permissions, there's "user", "group", and "world" octets. For the sake of this discussion, let's assume that setuid/sticky bits don't exist.
Consider the following example:
$ echo "Hello World" > strange
$ chmod 604 strange
$ ls -l strange
-rw----r-- 1 mrllama foo 12 Apr 13 15:59 strange
Let's assume that there's another user, john
, who is a member of my group, foo
.
- What permissions does John have regarding this file?
- Does the system go with the most specific permission match (i.e. John isn't owner, but he's in the
foo
group, so use the permissions for the "group" octet)? - …or does it go by the most permissive of the octets that apply to him (i.e. John meets the criteria for "group" and "world", so it goes with the more permissive of the two)?
Bonus questions:
- What if the permissions were instead
642
? Can John only read, only write, or both? - Are there any reasons to have strange permissions like
604
?
Best Answer
When determining access permissions using Unix-style permissions, the current user is compared with the file's owner, then the group, and the permissions applied are those of the first component which matches. Thus the file's owner has the owner's permissions (and only those), members of the file's group have the group's permissions (and only those), everyone else has the "other users'" permissions.
Thus:
642
, John could read the file.604
: this allows the group to be excluded, which can be handy in some situations — I've seen it on academic systems with astudents
group, where staff could create files accessible to anyone but students.root
has access to everything, regardless of the permissions defined on the file.For more complex access control you should look into SELinux and POSIX ACLs. (SELinux in particular can even limit what
root
has access to.)