Section 6.5. Objective 5: Use File Permissions to Control Access to Files
6.5. Objective 5: Use File Permissions to Control Access to FilesFilesystem 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. 6.5.1. Linux Access ControlNative 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 :
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 6-2.
These three permissions apply to the three different classes of users: user, group, and other. Each has read, write, and execute permissions, as shown in Figure 6-1. Figure 6-1. Access mode bits All of the permissions are binary (either granted or not granted) and are thought of as single binary bits in the access mode. When displayed by commands such as ls, the permissions use the mnemonic in Table 6-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:
Like the other access controls, these special properties are binary and are considered bits in the access mode. 6.5.1.1. The mode bitsThe special, user, group, and other permissions can be represented in a string of 12 binary bits, as shown in Figure 6-2. Figure 6-2. Changing permission bits to an octal number 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 6-3. 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 6-2 shows how to total bit values into the octal equivalents. Memorizing, or even writing, the binary-to-octal equivalents may be easier on the exam than adding bit values. Use the technique that works best for you.
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 + 0 = 6. The second group, representing user permissions, is 111, or 4 + 2 + 1 = 7. The third group, representing group permissions, is 101, or 4 + 0 + 1 = 5. The last group, representing other permissions, is 001, or 0 + 0 + 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 mount command is 4755: # stat /bin/mount File: "/bin/mount" Size: 53620 Filetype: Regular File Mode: (4755/-rwsr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Device: 3,2 Inode: 20335 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. 6.5.1.2. The mode stringAs 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 mount, 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. When the executable bits are set, the setuid and setgid bits are represented with s. When the executable bits are not set, the setuid and setgid bits are represented with S. Similarly, the sticky bit is represented with either t or T. 6.5.2. Setting Access ModesNew files are created with a default access mode to automatically set the permission levels. Regardless of your default umask, access modes on existing files can be changed or modified at will. 6.5.2.1. New filesWhen 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 0022 When provided with an integer, umask sets the value for the current shell: $ umask 2 $ umask 0002 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 .
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 22 (022) 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, although 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. As you can see in the output of the previous example, ls 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). 6.5.2.2. Changing access modesAccess 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 6-5.
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:
|
EAN: 2147483647
Pages: 257