1.23 File Access Permissions

Under UNIX, access to files is based on the concept of users and groups.

Every "user" on a system has a unique account with a unique login name and a unique UID ( 38.3 ) (user ID number). It is possible, and sometimes convenient, to create accounts that are shared by groups of people. For example, in a transaction processing application, all of the order-entry personnel might be assigned a common login name (as far as UNIX is concerned, they only count as one user). In a research and development environment, certain administrative operations might be easier if members of a team shared the same account, in addition to their own accounts. However, in most situations each person using the system has one and only one user ID, and vice versa.

Every user may be a member of one or more "groups." [3] The user's entry in the master password file ( /etc/passwd ( 36.3 ) ) defines his "primary group membership." The /etc/group ( 22.13 ) file defines the groups that are available and can also assign other users to these groups as needed. For example, I am a member of three groups: staff , editors , and research . My primary group is staff ; the group file says that I am also a member of the editors and research groups. We call editors and research my "secondary groups." The system administrator is responsible for maintaining the group and passwd files. You don't need to worry about them unless you're administering your own system.

[3] In Berkeley and other newer UNIX systems, users have the access privileges of all groups they belong to, all at the same time. In other UNIX systems, you use a command like newgrp to change the group you currently belong to.

Every file belongs to one user and one group. When a file is first created, its owner is the user who created it; its group is the user's primary group or the group of the directory it's created in . ( 22.5 , 22.13 ) For example, all files I create are owned by the user mikel and the group staff . As the file's owner, I am allowed to use the chgrp command to change the file's group. On filesystems that don't have quotas ( 24.17 ) , I can also use the chown command to change the file's owner. (To change ownership on systems with quotas, see article 22.21 .) For example, to change the file data so that it is owned by the user george and the group others , I give the commands:

% 

chgrp others data


% 

chown george data

If you need to change both owner and group, change the group first! You won't have permission to change the group after you aren't the owner. Some versions of chown can change both owner and group at the same time:

% 

chown george.others data

chown chgrp	If you need chown or chgrp for some reason, the GNU versions are on the CD-ROM.

File access is based on a file's user and group ownership and a set of access bits (commonly called the mode bits ). When you try to access a file, you are put into one of three classes. You are either the file's owner, a member of the file's group, or an "other." Three bits then determine whether you are allowed to read, write, or execute the file. So, as Figure 1.5 shows, there are a total of nine mode bits (three for each class) that set the basic access permissions.

Figure 1.5: Filesystem Permission Bits

It is common to see these nine basic mode bits interpreted as an octal (base-8) number, in which each digit specifies the access permitted for one class. Each three bits makes one octal digit. Figure 1.6 shows how to do it.

Figure 1.6: Changing Permission Bits to an Octal Number

Let's turn the mode bits 111101001 into an octal number. Break it into chunks of three bits: 111 101 001. The first group, 111, is 4+2+1 or 7. The second group, 101, is 4+0+1 or 5. The third group, 001, is 0+0+1 or 1. So those mode bits can be written as the octal number 751.

To tie this together, look at Figure 1.5 again-and work out these examples yourself. For example, if the owner of a file has read and write access, but no one else is allowed to touch the file, we say that it has the access mode 600. A file that is readable, writable, and executable by everyone has access mode 777. A file that is readable and writable by everyone (i.e., a public text file) has mode 666.

It is also common to see the mode bits expressed as a sequence of ten alphabetic characters (look at the listing from ls -l ( 22.2 ) ). The first character tells you the file's type. For a plain file, this character is a - . For a directory, it's a d . The next three bits report the owner's access, the middle three bits report group access, and the final three bits report access for others. An r indicates that read access is allowed, w indicates that write access is allowed, and x indicates that execute access is allowed. For example:

-rw-------
is mode 600

-rwxrwxrwx
is mode 777

-rw-rw-rw-
is mode 666

You can change a string like rw-rw-rw- into an octal number with the technique in Figure 1.6 Split it into three-bit chunks. For example, rw- would have the value 4+2+0-that's 6. Therefore, rw-rw-rw- is 666 octal.

If the file is executable, a few other bits come into play. One is the "sticky bit," which tells UNIX to leave the executable in memory after the program has finished running. In theory, leaving the executable around reduces the program's startup time for subsequent users. The sticky bit was an interesting idea a long time ago, but it is obsolete now: modern virtual memory techniques like demand paging have made it unnecessary. Many UNIX users and UNIX books still believe that the sticky bit does something important, so you will hear it mentioned from time to time.

More important are the "set user ID" and "set group ID" (SUID and SGID) bits. If you execute an SUID file, your user ID is set to the user ID of the file's owner. Therefore, if you execute an SUID file that is owned by root, you are the superuser-for the duration of the program. Likewise, executing an SGID file sets your group ID to the file's group while the file is executing. SUID and SGID files can be security holes, but they really exist to enhance security. For example, you might want to allow any user to create a backup tape, but you shouldn't give every user the root password. Therefore, you can create a special version of the dump utility that is owned by root and that has the SUID bit set. When a user invokes this utility, he or she will be able to back up the entire filesystem because the dump command will run as if it were executed by root. But the user can't do anything else: he doesn't know the superuser password and can't do anything that dump won't let him do. Used carefully, SUID programs can be a powerful administrative tool.

NOTE: SUID and SGID programs are such major security holes that many conscientious administrators refuse to add new SUID utilities. Some versions of UNIX ignore the SUID and SGID bits for shell scripts (command files)-on those versions, only compiled programs can be SUID or SGID. SUID and SGID programs always lose their special properties when they are copied. However, making SUID and SGID programs completely safe is very difficult (or maybe impossible). For better or for worse, a lot of standard UNIX utilities ( uucp and lpr , for example) are SUID. Article 22.1 introduces other information about file access permissions.