Sidebar: UNIX Filesystem and Permissions Revisited

The security of the Unix filesystem is based on a number of key factors. First, the identity of the user is important. This identity consists of two elements, a unique user id (uid) and a group id (gid). The uid is a number that uniquely identifies the user on the particular system. A user always belongs to at least one group, but can be a member of more than one group. Group ids are normally established along lines similar to the departments within the organization.

All files in a UNIX filesystem have two elements of ownership. Each file is owned by a specific user and also belongs to a group. Permissions relative to files are designated as read (shown as r in listings), write (shown as w in listings), and execute (shown as x in listings). Read permission allows you to look at the contents of a file, but not edit, change, or delete the file. Write permission allows you to take those actions.

Thus, when you do a long listing of a file using ls -l, these three permissions are reflected for the user, the group, and everyone else (referred to as "other"), preceded by a single character designator for the type of file. If a permission is denied, a dash appears in that space, as shown below. Execute permission on directories has a special meaning. It means that the directory file can be searched. If the directory is also readable, then files in the directory can be listed using ls or other utilities.

All programs that are started by a user normally run under his or her uid and gid. Exceptions to this rule are the setuid and setgid programs that execute under the uid or gid of the user or group that owns the file. If either of these permission bits are set, the x in the permissions listing is replaced by an s.

An example of a setuid program is the passwd program that you can use to change your password. The password is stored in the file /etc/passwd, and this file is normally writeable only by the superuser or root. So, if a normal user wants to write a new password to this file, it will normally fail. By making this program setuid to root, it will change its identity to root and thus, can write the new password in the passwd file. The following listing shows you the protection on the /etc/passwd file and the security mask for the passwd program. In this particular example, taken from Solaris 2.4, the /etc/passwd is not writeable at all, but luckily the superuser can change this on the fly.

bash$ ls -l /etc/passwd
-r--r--r--  1  root  sys  939 May  3 11:44 /etc/passwd
bash$

bash$ ls -l /usr/bin/passwd
-r-sr-sr-x  1  root  sys  11680 Jul 16 1994 /usr/bin/passwd
bash$

The s listing for the setuid bit does not truly replace the x bit, but rather is a combination of both the x bit and an invisible bit. If you cleared the x bit on a setuid program, the s would change into an S, meaning that the invisible bit is set and the x bit is cleared - an invalid combination.

The setgid (set group id) bit for executable files has the same meaning as the setuid bit, but only for the gid under which the program is running. So, setgid bit will change the file's group id to the group id that owns that file. The effect of setting the group id without corresponding execute permission is UNIX implementation dependent. Under Solaris, for example, this bit will change its meaning when the x bit is cleared. In that case, mandatory locking applies to that particular file, and the representation in the ls output will change from s to l.

The setgid bit also has a meaning when the related object is a directory. This, too, is implementation dependent. If you set this bit on a directory, all files created in this directory will inherit their group ownership from the group ownership of the directory itself. This behavior is derived from BSD UNIX and might not apply to your particular flavor.