Back to Basics With Unix Permissions
The most basic, yet important part of mastering Unix is to fully understand the nuances of file permissions. Tools exist to manage permissions easily, but true enlightenment and quick troubleshooting skills come to those who wholly master the concept. Remember, 80% of Unix problems are permissions issues.
At the most basic level, there are three types of access:
- Read – the ability to open a file and read it
- Write – the ability to write the file
- Execute – the ability to execute (run) the file
Directories, though similar, are subject to special rules. Write permissions on a directory imply that you can create new files and directories within. Execute permissions are required to 'cd' into the directory, and read permissions are required to list ('ls') the contents.
You will generally see permissions represented as r, w, or x; for read, write, and execute. Running 'ls -al' on the command line will show three sets of these strung together.
For example: -rwxr-xr-x
The dash means that the permission is not set. The first place is always reserved for special identifiers, like 'd' for directories or 'c' for character devices. The next place begins the actual permissions, for the user, group, and other categories.
Every access control in Unix is based on "who you are." The user is identified by the uid (user ID), as defined by a person's user account. The third field in the /etc/password file, for example, specifies what a user's uid is. Similarly, every user belongs to a default group, as identified by the fourth field in the passwd file. Users can belong to many groups, but they're always a member of their default group.
The above example of -rwxr-xr-x means that the owner of the file may read, write and execute it, the group members may read or execute it, and everyone else on the system may also read or execute the file.
A full example, from the output of 'ls -l' is:
-rw-r--r-- 1 charlie root 164 2006-12-10 23:51 test.js
The file named test.js is owned by me with read and write permissions, is set to the root group who can only read it, and also allows everyone else to read it.
How it Really Works
That's basically enough to get by, but being able to understand the more advanced modes of file permissions, your umask, and the numeric representation demands a full understanding. In reality, there are 8-bits available for each type of attribute. Take a look at Figure 1 and note that wherever you see a 1 in the binary column, a corresponding permission will exist.
As you can see, if a "bit" in a certain position of the binary representation is set, the permissions in that space are activated. The number column is the decimal representation, and the "Binary" column is how it really works, from the operation system's perspective.
Example time. Let's say we wish to give ourselves read/write/execute permissions, the group read/execute, and everyone else read/execute permissions. The following commands both do the same thing:
chmod u+rwx .; chmod go+rx .
chmod 755 .
Since we know that setting '5' means rx, we can simply say '5' instead of 'rx.' The real advantage to knowing the decimal representation is that we can set any arbitrary permissions with a single command. Running the chmod command using the mnemonics requires that we run it each time for each set of permissions.
Likewise, to set our umask, we must know how the permissions are numerically represented. The umask is the default mode with which files and directories will get created. It's a mask, so if we want to create all files with permissions like 755, we must take the mask. Simply subtract 7 from each item, and 022 reveals itself as the magic setting. See the umask man page for further details.
There are, in fact, three other modes you can set on a file or directory. All Unixes support the following:
- set user id (suid) on execution
- set group id on execution
- the sticky bit
If suid is enabled, the permissions look like this:
This means that when the file is executed, it will run with the permissions of the owner of the file. It's dangerous, but some times necessary and quite useful. For example, a file suid and owned by root will always run as root.
When sgid is enabled, the permissions look like this:
When set on a directory, sgid means that all files created within the directory will have the gid set to the current directory'd gid. This is handy when sharing files with other people, who will often forget to give other members read or write permissions.
The sticky bit looks like this:
When the sticky bit is enabled, only the owner of the file can change its permissions or delete it. Without the sticky bit, anyone with write permissions can change the modes (including ownership) or delete a file. This one is also handy when sharing files with a group of people.
There are other tidbits of information, once you get into the nuts and bolts of Unix file permissions too. For example, you can also set ACL attributes, which get horribly complex. Yes, you can give individual users access to your files, but it's better not to. Creating a new group and sticking to general permissions can accomplish most things. Often the extended attributes aren't necessary, and ACLs likely won't work over NFS if you're using Linux.
Spend some time with the chmod manual page to master tricky parts, if they still aren't clear. It will also mention some implementation-specific limitations you may need to be aware of.