On UNIX File Permissions

It is pretty shameful to say that i still get UNIX permissions wrong sometimes. I hope to make this final forever by writing about them here 🙂

Every file and directory has three set of permissions associated with it: owner’s permissions, group members’ permissions and others’ permissions. User identity is checked against these sets in this order and the first matching set is chosen, which has a side-effect that i always tend to ignore:

* File owner may have less permissions than group members

* Group members may have less permissions that others (i.e, rest of the world)

For example, a file can have rwx permissions for others, but no permissions for owner and group members. (Of course owner can change the file permissions to get what he wants, but thats irrelevant.)

Second point i always miss is, the semantics of directory permissions.

* Read permission on a directory means you can read the contents of the directory, which means you can read file names inside the directory (but not their attributes — you need execute permission for this.)

* Write permission on a directory means you can modify the contents of the directory, which means you can add new files, remove files, rename files, etc. (you don’t need to be owner of any of these files.)

* Execute permission on a directory means you can traverse the directory down to further sub directories (but you cannot list the files — you need read permission for this)

What is interesting here is, write permission to a directory is sufficient to add or remove any file in it, which also means — you don’t need to be the owner of that file to delete it. This point is necessary to understand the need for sticky-bit and is also a cause for old mkdirs’ time-of-check and time-of-use (TOCTOU) bug.

I will write a notes on set-user-id, set-group-id and sticky-bits some other time.