File Permissions

Here's a directory listing as produced by ls -l:

-rw-r--r--   1 mythtv users    1706 2005-10-13 14:01 release.keys

Here, the various columns mean the following:

`-rw-r--r--`	File permissions
`1`	number of links
`mythtv`	file owner
`users`	file-owning group
`1706`	file size
`2005-10-13 14:01`	creation time
`release.keys`	filename

This page concentrates on the first bit.

UNIX file permissions are made up of three groups: the user who owns the file, the group that the file belongs to, and other people. These letters are important as you can use them to instruct chmod(1) change the permission of the file.

For each part, you have read, write, and execute access. These are displayed as rwx.

Typically, system data files as well files served from a WebServer or such have -rw-r--r--, ie. they're readable for everyone but writable only for their owner; files with private data have -rw-------: readable and writeable only for their owner and noone else. Directories and executable files generally have -rwxr-xr-x: they're readable and executable for everyone but writable only for their owner.

Effects of permissions on directories

It's easy to understand what a particular set of permissions means for a file. On directories, it's less intuitive, so here are some explanations:

Having read permission on a directory means that you can see the list of files in that directory. It doesn't mean anything else; in particular, it doesn't mean that you can open the files, or get information about them via stat(2). Being able to read a directory means being able to list the files contained in the directory – no more, no less.

Having write access on its own means nothing. But together with execute access, it allows you to modify the directory. That means you can create or delete files or directories in it. You can delete a file even if you do not have any permissions to write or even read the file as long as you have write and execute permission for the directory in which the file resides.

The executable permission on directories means that you may use it as part of a path. F.ex., if user bob does not have execute permission for /var/queue/joe, he will not be able to read or stat /var/queue/joe/msg.371, even if he has read permission on the file itself.

Absence of read permission

If the /var/queue/joe directory from the last example has the execute permission set, but not the read permission, then bob will not be able to get a directory listing. (Remember? Read permission means you can get a directory listing.) However, if he knows the name of a file in that directory, eg. he knows that /var/queue/joe/msg.371 exists, and he has read permission for the file itself, then he can still read the file. Also, if he has write permission to the directory, he will be able to delete /var/queue/joe/msg.371, even though he cannot get a directory listing.

Modifying permissions

Permissions are altered on the Shell using chmod(1). (Missing here is an explanation of the 4=r, 2=w, 1=x mapping. Feel free to AddToMe.)

Generally, the fewer permissions you grant, the better. Most importantly, there's almost never a good reason to grant write permission to "other people".

Recursive chmod(1)

chmod(1) has a potentially very convenient switch: -R, which, as you'll suspect if you've used other UNIX tools, means "recurse into directories and apply the change to the entire directory tree." However, because directories need to be executable before you can refer to any of the files inside them, it would sometimes seem that this convenient switch cannot be used. F.ex., saying chmod -R a-x ./foo/ isn't very useful because that will make everything inside foo non-executable, including directories, which means you can't access any of it.

However, modern chmod(1)s understand a special pseudo-permission, called X (eg. uppercase X as opposed to x). It means "executable, but only when operating on a directory; no change otherwise". That way, you can say chmod -R a-x,a+X ./foo/, which will make chmod(1) remove the executable bit from every file but then also set the executable bit if it's a directory.

Before this feature was added, it was sometimes necessary to go through inconvenient contortions involing find(1) in order to operate only on files or only on directories. While that's still occasionally necessary, those occasions are now much rarer.

Sticky and setuid

There are actually two more permissions that are almost never useful outside of system files.

The setuid bit is shown with an s in directory listings. It specifies that when you execute the file, you assume the identity of the owner of the file. For example, if a file is owned by root and has the setuid permission set, it will run as root when you execute it, regardless of what your identity is. This is a way to allow regular users to do priviledged things; however it can easily lead to gaping security holes.

The sticky bit is shown with a t in directory listings is used for some widely shared system directories. It specifies that only the owner of a file can delete it. Normally, anyone who can create a file in a directory can delete any file in that directory. (To be precise, the owner of a directory with the sticky bit set can also delete any of the files in it.)