4.5 Objective 5: Use File Permissions to Control Access to Files Filesystem security is a fundamental requirement for any multiuser operating system. The system's files, such as the kernel, configuration files, and programs, must be protected from accidents and tampering by unauthorized people. Users' files must be protected from modification by other users and sometimes must be kept completely private. In general, a form of access control must be implemented to allow secure operations. 4.5.1 Linux Access Control Native Linux filesystem access control is implemented using a set of properties, maintained separately for each file. These properties are collectively called the access mode, or simply the mode, of the file. The mode is a part of the file's inode, the information retained in the filesystem that describes the file. A file's mode controls access by these three classes of users: - User
-
The user that owns the file. - Group
-
The group that owns the file. - Other
-
All other users on the system. Like the mode, user and group ownership properties are a part of the inode, and both are assigned when a file is created. Usually, the owner is the user who created the file. The file's group is usually set to its creator's default group. Group ownership adds flexibility in situations in which a team shares files. The "other" users are those who aren't members of the file's group and are not the file's owner. For each of these three user classes, the access mode defines three types of permissions, which apply differently for files and directories. The permissions are listed in Table 4-2. Table 4-2. File Permissions | Read | r | Examine the contents of the file. | List directory contents. | | Write | w | Write to, or change, the file. | Create and remove files in the directory. | | Execute | x | Run the file as a program. | Read and write files contained in the directory. | These three permissions apply to the three different classes of users: user, group, and other. Each has read, write, and execute capabilities, as shown in Figure 4-1.  All of the permissions are binary (either granted or not granted) and are thought of as single binary bits in the access mode. When written, the permissions use the mnemonic in Table 4-2 for the true state and a hyphen for the false state. To represent only the read permission, for example, r-- would be used. Read and execute together, typical for directories, would be denoted r-x. These notations are usually offered in sets of three, such as: rw-rw-r-- A file with this setting would give read/write permission to the user and group, and read-only permission to everyone else. In addition to the nine bits for user, group, and other, the access mode contains three more bits, which control special attributes for executable files and directories: - SUID (Set User ID)
-
The SUID property is for executable files only and has no effect on directories. Normally the user who launches a program owns the resulting process. However, if an executable file has its SUID bit set, the file's owner owns the resulting process, no matter who launched it. When SUID is used, the file's owner is usually root. This offers anyone temporary root access for the duration of the command. An example of an SUID program is lpr, the line print command. This command needs special access to manipulate the print spools, and runs as user root. Using the SUID bit in cases like lpr enhances security by allowing access to secure functions without giving away the root password. On the other hand, SUID can be a security risk if access is granted unwisely. - SGID (Set Group ID)
-
The SGID property works the same way as SUID for executable files, setting the process group owner to the file's group. In addition, the SGID property has a special effect on directories. When SGID is set on a directory, new files created within that directory are assigned the same group ownership as the directory itself. For example, if directory /home/fin has the group finance and has SGID enabled, then all files under /home/fin are created with group ownership of finance, regardless of the creator's group. This is an important attribute for teams, ensuring that shared files all have the same group ownership. - Sticky
-
At one time, the sticky property (more commonly known as the sticky bit), applied to executable programs, flagging the system to keep an image of the program in memory after the program finished running. This capability increased performance for subsequent uses by eliminating the programs' load phase, and was applied to programs that were large or were run frequently. Modern virtual memory techniques have made this use unnecessary, and under Linux there is no need to use the sticky bit on executable programs. When applied to a directory, the sticky bit offers additional security for files within the directory. Regardless of file permissions, the only users who can rename or delete the files from a directory with the sticky bit set are the file owner, the directory owner, and root. When used in a team environment, the sticky bit allows groups to create and modify files but allows only file owners the privilege of deleting or renaming them. Like the other access controls, these special properties are binary and are considered bits in the access mode. 4.5.1.1 The mode bits The special, user, group, and other permissions can be represented in a string of 12 binary bits, as shown in Figure 4-2.  It is common to refer to these bits in four sets of three, translated into four octal (base-8) digits. The first octal digit represents the special permissions SUID, SGID, and sticky. The other three represent the read, write, and execute permissions, respectively, in each of the user, group, and other user classes. Octal notation is used as shorthand for binary strings like the access mode, and each group of three bits has 23 = 8 possible values, listed in Table 4-3. Table 4-3. Octal Numbers | 0 | 000 | | 1 | 001 | | 2 | 010 | | 3 | 011 | | 4 | 100 | | 5 | 101 | | 6 | 110 | | 7 | 111 | The read permission by itself is r--, which can be thought of as binary 100, or octal 4. Adding the write permission yields rw-, or binary 110, which is octal 6. Figure 4-3 shows how to total bit values into the octal equivalents. To turn the mode bits 110111101001 into an octal representation, first separate them into chunks of three bits: 110, 111, 101, and 001. The first group, representing the special permissions, is 110. This can be thought of as 4 + 2 + = 6. The second group, representing user permissions, is 111, or 4 + 2 + 1 = 7. The third group, representing group permissions, is 101, or 4 + + 1 = 5. The last group, representing other permissions, is 001, or + + 1 = 1. The mode string for this example can then be written as the octal 6751. This is the form used to display the file mode in the output from the stat command. Here, the octal access mode for the lpr command is 4755: # stat /usr/bin/lpr File: "/mnt/hd/usr/bin/lpr" Size: 235672 Filetype: Regular File Mode: (4755/-rwsr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Device: 3,1 Inode: 176133 Links: 1 Access: Tue Aug 10 23:57:11 1999(00144.11:34:49) Modify: Tue Aug 10 23:57:11 1999(00144.11:34:49) Change: Wed Dec 8 20:59:02 1999(00024.13:32:58) The special permissions are represented in this example by octal 4, or binary 100, indicating that the SUID permission is set (-rws). The user permission is octal 7, or binary 111, indicating read, write, and execute for the file's owner (in this case, root). Both the group and other permissions are set to octal 5, or binary 101, indicating read and execute, but not write. 4.5.1.2 The mode string As mentioned earlier, the user, group, and other permissions are often spelled out in symbolic mode descriptions such as rwxr-xr-x. This notation is found in the output of the ls -l and stat commands. As you can see in the access mode for lpr, this scheme is modified slightly in the presence of special permissions. Instead of adding three more bits to the left of rwxr-xr-x, the SUID permission is indicated in the string by changing the user execute position from x to s. SGID permission is handled the same way. The sticky permission is indicated by replacing x in the other execute position with T. For example, an executable program with mode 6755 would have the following equivalent symbolic mode: rwsr-sr-x A directory with mode 1774 would have this equivalent string: rwxr-xr-T While this layering of special permissions may appear to obscure the underlying execute permissions, it makes sense. The special permissions are relatively rare in the filesystem, so depicting the three extra bits would waste space on your terminal or terminal window. In addition, the special permissions are used only for executable programs and directories, where the underlying executable permission is understood to be set.  4.5.2 Setting Access Modes New files are created with a default access mode to automatically set the permission levels. But just because a permission level is set automatically doesn't mean that you have to live with what you're given. Access modes on existing files can be changed or modified. 4.5.2.1 New files When new files are created, the protection bits are set according to the user's default setting. That default is established using the umask command, probably in a startup script. This command accepts only one argument, which is a three-digit octal string that masks the user, group, and other permission bits for newly created files and directories. Without a value, umask reports the current value: $ umask 22 When provided with an integer, umask sets the value for the current shell: $ umask 2 $ umask 2 A umask of 22 can be rewritten as 022, or as 000010010 in binary. The process of creating the initial mode for newly created files begins with a raw initial mode string, as defined in Table 4-4. Table 4-4. Initial Access Modes | Symbolic | rw-rw-rw- | rwxrwxrwx | | Binary | 110110110 | 111111111 | | Octal | 6 6 6 | 7 7 7 | The special bits are always turned off and are not masked by the umask. When a file is created, the umask is subtracted from 666; for directories, it is subtracted from 777. This calculation yields the effective protection mode for the file or directory. For example, a umask of 2 (002) is applied to a new file, masking the write permission for group and other user classes: 110 110 110 - 000 010 010 -------------- 110 100 100 This is the same as mode 644, or rw-r--r--. Using the same mask on a directory yields a similar result: 111 111 111 - 000 010 010 -------------- 111 101 101 This is the same as mode 755 or rwxr-xr-x, which is appropriate for directories. A umask of 002 or 022 is typical, though if you wish to ensure maximum privacy, a umask of 077 blocks all access except for the superuser. To set a custom umask, enter the umask command in a startup script, such as .bash_ profile. Here's an example of the umask in action: $ umask 27 $ touch afile $ mkdir adir $ ls -ld adir afile drwxr-x--- 2 jdean jdean 1024 Jan 2 20:31 adir -rw-r----- 1 jdean jdean 0 Jan 2 20:31 afile In this case, the umask of 27 makes the file afile read-only to members of the group and disallows access to the file to all others. In the previous example, the command ls -ld adds an extra letter at the beginning of the mode string for the adir directory. This symbol indicates the type of file being listed and is not part of the access mode. The letter d indicates a directory, a - indicates a file, the letter l indicates a symbolic link, a b indicates a block device (such as a disk), and a c indicates a character device (such as a terminal). 4.5.2.2 Changing access modes Access modes can be changed with the chmod command, which accepts either octal or symbolic access mode specifications. Octal bits, as shown in the previous section, are specified explicitly. However, some people prefer to use symbolic forms because they usually modify an existing mode instead of completely replacing it. Symbolic mode specifications have three parts, made up of individual characters, as shown in Table 4-5. Table 4-5. Symbolic Modes for the chmod Command | User class | u | User. | | | g | Group. | | | o | Other. | | | a | All classes. | | Operation | - | Take away permission. | | | + | Add permission. | | | = | Set permission exactly. | | Permissions | r | Read permission. | | | w | Write permission. | | | x | Execute permission. | | | X | Execute permission for directories and files with another execute permission, but not plain files. | | | s | SUID or SGID permissions. | | | t | Sticky bit. | The individual user class characters and permissions characters may be grouped to form compound expressions, such as ug for user and group combined or rw for read and write. Here are some examples of symbolic mode specifications: - u+x
-
Add execute permission for the user. - go-w
-
Remove write permission from group and other classes. - o+t
-
Set the sticky bit. - a=rw
-
Set read and write, but not execute, permissions for everyone. - a+X
-
Give everyone execute permission for directories and for those files with any existing execute permission. The chmod command is used to modify the mode.
Syntaxchmod [options] symbolic_mode[,symbolic_mode]... files chmod [options] octal_mode files chmod [options] --reference=rfile files Description Modify the access mode on files. In the first form, use one or more comma-separated symbolic_mode specifications to modify files. In the second form, use an octal_mode to modify files. In the third form, use the mode of rfile as a template to be applied to files. Frequently used options - -c
-
Like verbose mode, but report only changes. - -R
-
Use recursive mode, descending through directory hierarchies under files and making modifications throughout. - -v
-
Use verbose behavior, reporting actions for all files. Example 1 Set the mode for a file to rw-r--r--, using an octal specification: $ chmod 644 afile $ ls -l afile -rw-r--r-- 1 jdean jdean 0 Jan 2 20:31 afile Example 2 Set the same permission using a symbolic specification, using the verbose option: $ chmod -v u=rw,go=r afile mode of afile retained as 0644 (rw-r--r--) Example 3 Recursively remove all permissions for other on a directory: $ chmod -v o-rwx adir mode of adir retained as 0770 (rwxrwx---) mode of adir/file1 changed to 0660 (rw-rw----) mode of adir/file2 changed to 0660 (rw-rw----) mode of adir/file3 changed to 0660 (rw-rw----) mode of adir/file4 changed to 0660 (rw-rw----) mode of adir/dir1 changed to 0770 (rwxrwx---) mode of adir/dir1/file6 changed to 0660 (rw-rw----) mode of adir/dir1/file5 changed to 0660 (rw-rw----) mode of adir/dir2 changed to 0770 (rwxrwx---) Example 4 Set the sticky bit on a directory: $ chmod -v +t adir mode of adir changed to 1770 (rwxrwx--T) 4.5.3 Setting Up a Workgroup Directory The steps you may use to create a useful workgroup directory for a small team of people are briefly described here. The goals of the directory are as follows: -
The workgroup is to be called sales and has members jdoe, bsmith, and jbrown. -
The directory is /home/sls. -
Only the creators of files in /home/sls should be able to delete them. -
Members shouldn't need to worry about file ownership, and all group members require full access to files. -
Nonmembers should have no access to any of the files. The following steps will satisfy the goals: -
Create the new group: # groupadd sales -
Add the existing users to the group: # usermod -G sales jdoe # usermod -G sales bsmith # usermod -G sales jbrown -
Create a directory for the group: # mkdir /home/sls -
Set the ownership of the new directory: # chgrp sales /home/sls -
Protect the directory from others: # chmod 770 /home/sls -
Set the SGID bit to ensure that the sales group will own all new files. Also set the sticky bit to protect files from deletion by non-owners: # chmod g+s,o+t /home/sls -
Test it: # su - jdoe $ cd /home/sls $ touch afile $ ls -l afile -rw-rw-r-- 1 jdoe sales 0 Jan 3 02:44 afile $ exit # su - bsmith # cd /home/sls # rm afile rm: cannot unlink `afile': Operation not permitted After the ls command, we see that the group ownership is correctly set to sales. After the rm command, we see that bsmith cannot delete afile, which was created by jdoe. We also note that although afile has mode 664, the directory containing it has mode 770, preventing other users from reading the file. | For the exam, you should be prepared to answer questions on file and directory permissions in both symbolic and numeric (octal) forms. You should also be able to translate between the two forms given an example. |  |
