Volume Number: 19 (2003)
Issue Number: 6
Column Tag: Section 7

Section 7

File Mode Idioms

by Rich Morin

Each Mac OS X file system node has a 16-bit mode word, as described in chmod(1,2) and stat(2). This word specifies the node's type, what access modes are allowed, and some specialized handling. 16 bits provides 64 K possible variations, but only a relatively small number of "file mode idioms" are found with any frequency. By learning some of these idioms, you can make your system more secure and understand existing configuration decisions.

Before we get into the idioms, however, let's review the basics of file types and modes. The file system recognizes many types of "files", including a number of things (e.g., directories) that aren't really files, at all. The most common file type, however, is the "regular file", followed by the "directory" and the "symbolic link" (aka symlink(7)).

There are dozens of device files (see mknod(1,2,8) for details), but they are almost always segregated into the /dev directory. Sockets and named pipes can be used to enable interprocess communication between arbitrary processes (see mkfifo(2) for details). Finally, the "whiteout" type is used for the (ever-experimental) Union File System, described in FreeBSD's mount_union(8) man page.

The node's type is specified by the top four bits in the mode word, available via the stat(2) system call:

0160000  whiteout
0140000  socket
0120000  symbolic link
0100000  regular file
0060000  block special device
0040000  directory
0020000  character special device
0010000  named pipe (fifo)

The next three bits specify some forms of "special handling". If the node is a regular file, the bits are interpreted as follows:

0004000  set user  id on execution
0002000  set group id on execution
0001000  save swapped text, even after use

The first two bits are described in the setuid(2) man page. Briefly, they allow a program to run with the permissions of its owner (or group), rather than those of the user who started it. This is used to provide controlled access to elevated privileges in (carefully constructed!) system commands.

You can get a list of your system's setuid and setgid commands with the following C-shell command (use whereis(1) or which(1) to find the full path name of a specific command). In the output below, df is setgid to "operator" and rcp is setuid to "root":

% ls -l /{,usr/}{,*/}{,s}bin | grep '[r-]-s'
-r-xr-sr-x  1 root  operator  ...  df
-r-sr-xr-x  1 root  wheel     ...  rcp
...

The third bit, described in sticky(8), tells the system to retain the read-only parts of a program's image in memory, after the program has terminated. This can be used to reduce the start-up time for frequently-run programs. Whether your OS honors the request is, of course, up to the vendor (:-).'

If the node is a directory and the system is SysV-ish (e.g., Red Hat Linux), the setgid bit may be interpreted as forcing "BSDish" behavior in setting the group for a new file. That is, a new file will get the enclosing directory's group, rather than the user's. On BSDish systems (e.g., OSX), this bit has no effect.

Sticky directories are a bit more complex; here's a snippet from the manual: "A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp, which must be publicly writable but should deny users the license to arbitrarily delete or rename each others' files."

The bottom nine bits are divided into three sets of permissions (for the file's owner, members of the file's group, and everyone else); each set specifies read, write, and execute permission:

0000400  read  permission, owner
0000200  write permission, owner
0000100  execute/search permission, owner
0000040  read permission, group
...

The meanings of read, write, and execute are a bit strained, when it comes to directories. Read permission allows the user to "read" the directory, looking for file names, etc. Write permission allows the user to "write" the directory, creating or removing files, etc. Finally, execute permission allows the user to access an item contained within the directory.

Most files are readable and writable by their owners. If nobody else is expected to access the file, no other permissions are needed. However, it is common to allow group access, as well:

% touch 0600 0660
% chmod 0600 0600
% chmod 0660 0660
% ls -l 0*
-rw-------  ...  0600
-rw-rw----  ...  0660

Obviously, executable files need to have the appropriate "execute" bits set. Less obviously, the "read" bit must be set for scripts (so the interpreter can read them!). In practice, even binary executables tend to have read access turned on; for one thing, this allows debuggers to inspect the binary.

Distributed executables often have write access turned off. This seems like a good idea, because it reduces the chance of inappropriate modification. An inspection of /usr/bin on my OSX system, however, shows that this practice isn't universal:

-rwxr-xr-x  ...  cscope
-r-xr-xr-x  ...  ctags

System-wide files, such as the executables in bin directories, generally need to be accessible by everyone on the system. Many system control files also need universal read access:

-r--r--r--  ...  /etc/crontab

sudo(8) allows any command to be run as if by any specified user, assuming that the actual user can supply the required password. Unfortunately, this requires passwords to be handed out, remembered, guarded, etc. Fortunately, the file system provides an elegant solution:

-rwsr-x---  1 root  wheel  ...  so

The "so" command (at least our version :-) gives root privileges to anyone who is in group wheel. If arguments are given, they are run as a command line; otherwise, the user is given a root-enabled shell.

The mode bits for home directories should keep each user's files safe from casual inspection (let alone modification). Depending on the environment, and your own level of paranoia, one of the following is probably appropriate:

drwx------  ...  abc  grp1  ...
drwx--x---  ...  def  grp2  ...
drwxr-x---  ...  ghi  grp3  ...
drwxr-x--x  ...  jkl  grp4  ...
drwxr-xr-x  ...  mno  grp5  ...

User abc doesn't want anyone else doing anything with his files. User def is willing to let members of group grp2 access files, but only if they know the file's name (removing read access from directories turns off ls access, wild cards, etc.). User ghi seems to trust his group fairly well, but still doesn't want them creating files in his home directory.

Users jkl and mno trust everyone on their computer as much as users def and ghi trust members of their groups. Because security tends to be antithetical to convenience, user ghi has the least problems sharing files, etc. For what it's worth, I use mno's mode on my desktop machine and jkl's mode on my server account.

Allowing directory execute access by others can be quite useful. Let's say that you want to set up a "drop box" where other users can leave files. Anyone should be able to drop stuff off, but only you should be able to look into the box, retrieve files, or (gasp!) remove files. Here's how:

% chmod 1733 drop_box
% ls -d drop_box
drwx-wx-wt  ... drop_box

As the owner, I am allowed to do anything to the directory. Others (including members of my group) are allowed to access and even create files in the directory, but they are not allowed to list its contents. Finally, the "sticky" bit (described above), keeps anyone but me from removing files from the directory.

I encourage you to set up a "testbed" directory and try out different modes within it. Try out different combinations to see how they might be useful; all of this will pay off some day when you're trying to figure out an obscure "file not found" or "permission denied" error message!

Rich Morin has been using computers since 1970, Unix since 1983, and Mac-based Unix since 1986 (when he helped Apple create A/UX 1.0). When he isn't writing this column, Rich runs Prime Time Freeware (www.ptf.com), a publisher of books and CD-ROMs for the Free and Open Source software community. Feel free to write to Rich at rdm@ptf.com.