Unix File Permissions Cookbook
From DreamHost
So, you've read how to use Unix File Permissions, but what use are they?
Well, they can keep everybody out of your private files or you can grant everybody full access. They can be used to make managing a group project easier and can allow you to give certain folks access to parts of your web site without granting access to everything.
Contents |
Recipe: Private Directory
To make all your files private you can do this a few different ways. The easiest would be to just make it so that nobody can get into the directory containing all the files. Then the rest of the permissions don't matter.
$ chmod 700 private_directory
Now, no one but you, the owner, can see the file in private_directory
Recipe: Listable Directory, but Unreadable Files
As an alternative, you might want somebody to see what files you have, but not actually be able to read any of them:
$ chmod 755 private_directory $ chmod go-rwx private_directory/*
This makes it so that all the files (and subdirectories) within private_directory are now inaccessible to anyone but you. However, everyone can list the files there and see the file names and sizes, etc.
Recipe: Partially Private Files
You can make select files private by removing the read permissions on just those files. Doing so on directories will make those directories unlistable.
$ chmod go-rwx file1 file2 file3 file4
Recipe: Web Site
Normally, web files are not private (otherwise, they probably wouldn't be on the web). For this you need to make sure your file permissions are all set correctly. Let's say your web directory is named example.com:
$ cd ~ $ chmod 711 . $ chmod 755 example.com $ chmod 644 example.com/*
The first chmod makes it so that others can get into your directory, but not see what files are there (the bare minimum needed for the web server to get in because it already knows what directory it is looking for). The second chmod makes it so the web server can see what files are available to show. The third chmod sets all the files in the directory readable to the file server and editable by you.
This will not work if you have subdirectories, such as an images folder. A shortcut is to say:
$ cd ~ $ chmod 711 . $ chmod -R u+w,a+rX example.com
The first chmod is the same as before. The second requires a little explaining.
- -R
- The "R" stands for "Recursive", which is a fancy way of saying, do the same to all files and subdirectories of example.com and all the files and subdirectories of those and so on until you hit every file.
- u+w
- Give yourself permission to write all the files and directories (this is probably redundant).
- a+rX
- Give everyone (user, group, and other) the ability to read all files and directories. The uppercase "X" has a special meaning. A plain "x", would make all of your files executable programs—which is not what you want for HTML files, they are not programs! The uppercase "X" tells chmod to only make directories executable and leave the rest of the files as is.
Recipe: Setting permissions separately
This recipe allow setting permission for files and directories separately.
$ find . -type d -print0 | xargs -0 chmod 705 $ find . -type f -print0 | xargs -0 chmod 604
find looks for directories or files (specified by -type argument) and outputs names in \0 separated list. The list is then feeded to xargs command which applies chmod to every element of the list.
Recipe: Maintaining Group Ownership
Probably the coolest feature is the ability to set the sticky bit on a directory for groups. Let's say you have 5 different people in charge of editting your site. You can, if you choose, just give everybody access to the web site account with one username and password. Well, as a systems administrator myself, I have experienced what a problem group accounts are. Group accounts provide very little accountability, so users tend to be a little more free with passwords to those accounts. It also means that when changes are made to the web site, you never know who made the changes.
Solution: Create an individual account for each user. Create a group, we'll call it "webmasters," and add each of your editors to that group. Set up the site directory, we'll call it "example.com," so that it is group owned by "webmasters" and group writable. Then, set the sticky bit on each of the directories. Here we assume we haven't put any files in the site yet and we're just setting it up, so you can just set the sticky bit on the top directory.
$ cd ~ $ chgrp webmasters example.com $ chmod 2775 example.com
Now, any file created in example.com will be created with "webmasters" as the group owner, but with the user who created it as the user owner. They can then adjust the permissions on the file and anyone can modify the file. Furthermore, any directory created with example.com will automatically have the group sticky bit set, so files created within those will follow the same rules.
The more interesting solution is to create more than just one group and that way you can allow different groups to modify different parts of the web site. Of course, getting this complicated might make a CMS desirable, but sometimes not. In some cases, this is useful with a CMS so that you can grant some user or group of users temporary access to parts of the CMS, etc.
