Unix File Permissions
Part 3
by Kurt Keller
The most common things you should know about Unix file permissions were
already covered in the previous two parts of this article. In this last
part we are going to have a look at some of the more special settings
and related issues. These settings might not be as common as what we
have covered up to now, but they are non the less interesting and
important.
Up to now, we only have seen four characters used for representing the
permissions on files and directories: -, r, w and x. Once in a while, however,
you might stumble across some other letters at the three places where an x can
be. This happens if some special bits are assigned.
Normally, when you execute a program, the program will run with your
privileges and in your context. But there are situations, where normal
users require elevated privileges in order to get some task done. One
prominent example is changing your own password. A hashed
representation of each user's password is stored in a file which is only
readable and writable by the root user. When a normal user wants to change
his or her password, this file must be updated. But a normal user does not
have read, save write permissions for this file. So the program which
changes the password must be running on behalf of the user but with the
privileges of the root user. For such situations a special bit can be
set on the file permissions, the so called
set-user-ID bit,
usually written as SUID. When this bit is set, the program it is
applied to, does run with the privileges of the file owner.
Doing a long file listing, this bit
will show up as an s instead of an x in the owner permissions. A
lowercase s means both, the SUID bit and the execute bit are set. An
uppercase S represents a SUID bit without the execute bit.
When you do a long listing of the /usr/bin/passwd executable file, you
will see it is owned by root and the SUID bit is set. The permissions
specify that every user can run the program. Because of the SUID bit,
every user will run this program with root privileges, which makes it
possible to update the read and write protected file containing the
password hashes. You might imagine that writing programs which are to be
run with the SUID bit set, is a big challenge and needs a lot of thought
to prevent misuse, especially if the owner of the utility is root, the
allmighty superuser on Unix systems. Setting this bit on certain programs,
for example on a text editor providing shell escapes, and making them
owned by root, is a convenient backdoor to hack a system, by the way.
The SUID bit can also be set on directories. As you would expect, it
does have a different meaning there. When set on a
directory, all the files and directories created within this directory
will have the same owner as the SUID-directory itself, no matter who
created the file. This is a feature which is not used too often, but it
can be useful in some cases.
Knowing what the SUID bit does, it is not difficult to correctly guess
what the SGID or set-group-ID
bit is for. While executing a program with this bit set, you will
automatically inherit the privileges of the group owning the program.
This usually is used for various
utilities of some subsystems, like the mail subsystem or the printing
subsystem etc.
Just like the SUID bit, the SGID bit is
represented with a lowercase or uppercase s at the place you would
normally expect to find the x for the group execute bit.
A SGID bit on a directory can mean that all files created in the
directory inherit the group of the directory and subdirectories will
also inherit the SGID bit.
There is no such thing as a SWID or set-world-id bit. This would be
nonsense, since by default programs are already executed as the user and
the group of the invoking user. But there is a special bit which can
transform the x of the world executable bit. This does
not change the last x to a s, but to a t instead. Again, if at the same
time the
applicable execute bit is set, the t is printed in lower case in a long
listing, if the execute bit for the world at large is not set, the T is
upper case.
Some systems assign a special meaning
to the sticky bit for files, but not all the versions of Unix use this
bit on files for the same purpose. Often it is used for specifying
whether data associated with this file can be written to swap or not.
The sticky bit is usually used on publicly writable directories. The
directory /tmp is such a place. All the users should be able to write to
this directory in order to save temporary files. May programs assume they can
write their temporary files to /tmp. For this to work, the directory
must be world writable. However, as we've seen before, any user can
delete and rename any file of any other user in a world writable
directory. It is here where the sticky bit comes into play. If the
sticky bit is applied to a directory, a file in that directory can only
be deleted or renamed if the user has write permission to the directory
itself and in addition to this he is either the owner of the file, the
owner of the directory itself or the superuser (root). So the sticky bit
makes your files stick to you and prevents users to delete and rename
other users' files in publicly writable directories.
Some of the purposes of these three special bits are not the same on
all Unix systems. The SUID and SGID bit on files with the applicable
execute bits also set, as well as the SUID and the sticky bit on
directories, should be quite standard. But to be sure what exactly the
other cases mean on your particular version on Unix, it is best to
consult the applicable manual pages, mainly the ones for chown and stat.
Sofar we have been talking about file permissions as the letters
r, w, x, s, t and - all the time. It is absolutely possible to get by with this.
However, when you watch somebody doing system administration or when you
read technical publications or software documentation,
you'll hardly ever see this method to refer to file permissions. Usually
a numeric representation of the permissions is used. It is not difficult
to map the permissions to the numeric representation, as long as you can
add up three digits.
We can write the number 4 under each read
permission, the number 2 under each write permission and the number 1
under each execute permission. Now, for each of the three groups, owner,
group and world, you simply add the numbers of the permissions which
should be set and you have the numeric representation of it. Let's do an
example:
The owner has full permissions, r and w and x are all set, so when we do the
math: 4+2+1 we get 7. The group does have read and write permissions, so
it's 4+2+0=6 and the world at large only has read permission: 4+0+0=4.
All in all, we get 764 for the numeric representation. That is not seven
hundred sixty four, but seven for owner, six for group and 4 for
world: seven, six, four! Often you will see four digits, rather than
three. The leading digit, which in our case is zero and not shown here,
specifies the values to use for SUID, SGID and sticky bit. SUID is 4,
SGID is 2 and sticky bit is 1, the calculation is the same. So trying to
explain this visually, we get what is depicted in
figure 3:
Figure 3:
filemodes and their numeric
representation
 |
Now you have learnt a lot about Unix file permissions and are ready to
go out into the world and apply your newly gained knowledge. There is
just one more question I'm burning to ask...
What are the permissions used when you create a new file or directory?
After all, every file and directory does have permissions so what is used
for default values? First of all, almost any system will disable all execute
permissions when you create a new file. Making a new directory, however
will leave the execute bits turned on, otherwise you'd not be able to
change into the directory. So if nothing else is set, directories will
have permissions wrxwrxwrx (or 0777) and files wr-wr-wr- (or 0555). But
if you actually do try it out, it is more likely your new directories
will have permission 0755 and files 0644. This is because of the so
called umask. Most systems set the default umask to 022 but you
could change your own umask with the umask command to another
value. What the heck is an umask, anyway? We just heard about the numeric
representation of the file permissions and how they can be expressed
with the digits 4, 2 and 1. The value passes to umask is a filter
specifying the bits which are to be dropped when creating files and
directories. So if you have a look at
figure 4,
you can see the umask 022 in action and
also how the execute bit is automatically dropped for files. SUID, SGID
and sticky bits are rather special and never considered for creating new
files and directories, so they are dropped automatically (unless some
special bits on the parent directory turn them on, that is). Starting
out with
the maximum possible of the normal permission bits, we let them fall onto
the filter. At the positions where the filter has an entry, the
permissions get caught and will not drop down to be
applied to a new
directory. When creating a new file, the remaining permissions are
dropped onto another, automatic filter, snatching all execute permissions
and letting pass through the rest. What falls through to the bottom
will be the permissions being applied to a new file.
Figure 4:
filemode numeric representation and default creation
mode
 |
On a new server I am playing around with, I always happen to get myself into
trouble again. This machine sometimes is being abused for some quick and
dirty tests. From another machine I copy some script or executable
into the /tmp filespace to check whether it will behave properly on this
version of the OS or with this setup. However, the script or executable
will not run at all. After the third try, I usually remember why it would
not run: on this machine /tmp is a separate filespace and mounted with a
special option which renders all execute permissions on any files in
this filespace useless.
Almost everybody understands the concept of
read-only filesystems. On 5.25" floppy disks you put a black or silver
sticker over the small hole on the right edge in order to write protect
it, on 3.5" floppy disks you opened the latch in the upper right corner
to make it read-only, program CD's are read only media and filesystems
can be mounted read-only. On modern Unix systems there is not only the
read-only mount option, but a whole lot more.
Among others,
there can be the noexec mount option, which disables all execute
flags, the nosuid mount options which disables all SUID flags,
and of course the rdonly mount option, which makes
the whole filesystem mounted with this flag unwritabe, no matter what
the permissions on directories and files on this filesystem are. So, if you
believe the permissions on a file or directory are correct but you still
can't do with the file or directory what you are supposed to be able doing,
according to the
file permissions, you might want to check the mount options of the
filesystem involved.
Finally, there are also a number of settings on some systems
which are more or less invisible to the user but can restrict him or her
severely. Things like Access Control Lists (ACL), trusted
computing base, role based computing etc. can all influence what you can
and can not access on a computer. Of course this does include files.
These things
are still rarely used, but will play a greater role in the future. I
can remember well when an otherwise savvy Lotus
Notes administrator came to me and simply could not understand the world
any more. Lotus Notes was supposed to be installed on that machine and
it was running, happily serving web pages and replicating databases. But
when she logged in to the machine she could not find a single Lotus
Notes database on it, neither any logfiles, ini-files etc. and still, the
machine was miraculously working. The machine in question was
running a trusted operating system and in the security context used for
logging in to the machine, Lotus Notes was just not visible. Only when
the Notes admin switched security contexts with a special command could
she see her
files. But even then was it not possible to edit or access all the files
belonging to Lotus Notes, only the ones I had configured to be
accessible by her.
Well, now you have read a lot about file permissions on Unix. Possibly
not everything is really clear yet, but using these things, most of it
will become clear sooner or later. And you can always come back here
for some explanations on how it works, or at least how it is supposed
to work.