If you collaborate with others on a shared filesystem, you will invariably run into permissions problems. Read this to understand why and what you can do about it.
Every file and directory on a unix filesystem has a set of permissions that define what each user is allowed to do with it. These permissions consist of:
Additionally, files might be executable by the owner, group, and/or others; and directories might be listable by the owner, group, and/or others. Even more confusing is the existence of the SetUID mode for both files and directories. (This article will not cover SetUID; that deserves an entire article to itself.)
Wrong permissions can cause lots of headaches. While they usually work fine on your own personal laptop, any potential collaborators sharing your filesystem might be greeted with fun errors and warnings while working. For instance, they might be unable to change the modification times:
$ cp -p hws.ini inputFiles/hws.ini
Need read and write permission on ./inputFiles/hws.ini. Date hints have not been updated.
...even when they can write to the file. Or they might be unable to change the file permissions:
$ chmod ug+w index.html
chmod: changing permissions of 'index.html': Operation not permitted
...even when deleting and re-creating the file works fine.
To clarify why these bizarre situations come up, here's a handy table illustrating the (often confusing) permissions settings you need to make various changes.
| operation | required permissions |
|---|---|
| create a file or directory | have the write permission on the parent directory |
| delete a file or directory | have the write permission on the parent directory |
| modify a file | have the write permission |
| execute a file | have the read and execute permissions |
| change a file or directory's owner | not allowed |
| change a file or directory's group | be the owner and be a member of the new group |
| modify a file or directory's permissions | be the owner |
| modify a file or directory's other metadata (modification time, etc.) | ? |
| show the contents of a directory | have the "list" permission |
To clarify further, you have the X permission if any of the following are true:
There are good reasons for all of these restrictions—albeit somewhat silly ones. Note, of course, that the root user can ignore any and all of the above restrictions.
Why can't I "give away" my files to another user? This is to prevent you from sneaking around disk quotas on shared systems. If you had the ability to change the user on your own files, you could give them to unsuspecting users whenever you got too close to your disk quota, then take them back when you need them (assuming the unsuspecting users never delete or modify the files).
Why can't I change the permissions on a file I can write to (but that I do not own)? For directories, this restriction makes sense: sometimes you want to set up a directory that other users can collaborate in, but not allow those users to modify the directory itself. At UW, this feature is used to set up shared folders for professors and TAs to manage class websites: the professors can modify their class website, but not the website folder itself. For files this feature seems a little silly, but it makes some sense that files should obey the same rules as directories as much as possible.
Why can I delete a file I cannot write to? If you are the owner of a directory, you should have the ability to manage that directory, including removing any bad files that other pesky users put there.
This system of rules also leads to some surprising possibilities.
If you are working alone on a personal machine, they can be whatever you want. They should be permissive enough for you to get your own work done.
If you are working alone on a shared machine, they should be permissive enough for you to get your own work done, but secure enough that you aren't sharing data with others. You might consider revoking the read/write permissions for others from your files:
$ chmod -R go-rwx .
If you are working with someone else on a shared machine, it is best if you and your collaborators are in a group together. Make sure that the group has read and write permissions for all files and directories. Be careful to always make your permissions permissive enough: your collaborators will not be able to change the permissions of your files, even if you give them write access!
Every symbolic link has the same permissions as its target. A change to either one is a change to the other as well. However, a symbolic link can have a different parent directory than its target. Therefore, operations that only require parent directory permissions—such as deleting a symbolic link but not its target—can differ between a symbolic link and its target.
Hard links share all their metadata, including owner, group, and permissions. This can be very surprising! If you change the owner of a file, you are also changing the owner of every hard link to that file.