In addition to the controls imposed by SELinux (page 400), CentOS Linux supports two methods of controlling who can access a file and how they can access it: traditional Linux access permissions and Access Control Lists (ACLs, page 185). ACLs provide finer-grained control of access privileges. This section describes traditional Linux access permissions.
Three types of users can access a file: the owner of the file (owner), a member of a group that the file is associated with (group; see page 451 for more information on groups), and everyone else (other). A user can attempt to access an ordinary file in three ways: by trying to read from, write to, or execute it.
ls l: Displays Permissions
When you call ls with the l option and the name of one or more ordinary files, ls displays a line of information about the file. The following example displays information for two files. The file letter.0610 contains the text of a letter, and check_spell contains a shell script, a program written in a high-level shell programming language:
$ ls -l letter.0610 check_spell -rw-r--r-- 1 alex pubs 3355 May 2 10:52 letter.0610 -rwxr-xr-x 2 alex pubs 852 May 5 14:03 check_spell
From left to right, the lines that an ls l command displays contain the following information (refer to Figure 6-12):
The type of file (first character)
The file's access permissions (the next nine characters)
The ACL flag (present if the file has an ACL, page 185)
The number of links to the file (page 190)
The name of the owner of the file (usually the person who created the file)
The name of the group that the file is associated with
The size of the file in characters (bytes)
The date and time the file was created or last modified
The name of the file
Figure 6-12. The columns displayed by the ls l command
The type of file (first column) for letter.0610 is a hyphen () because it is an ordinary file (directory files have a d in this column).
The next three characters specify the access permissions for the owner of the file: r indicates read permission, w indicates write permission, and x indicates execute permission. A in a column indicates that the owner does not have the permission that would have appeared in that position.
In a similar manner the next three characters represent permissions for the group, and the final three characters represent permissions for other (everyone else). In the preceding example, the owner of letter.0610 can read from and write to the file, whereas the group and others can only read from the file and no one is allowed to execute it. Although execute permission can be allowed for any file, it does not make sense to assign execute permission to a file that contains a document, such as a letter. The check_spell file is an executable shell script, so execute permission is appropriate for it. (The owner, group, and others have execute access permission.)
chmod: Changes Access Permissions
The owner of a file controls which users have permission to access the file and how they can access it. When you own a file, you can use the chmod (change mode) utility to change access permissions for that file. In the following example, chmod adds (+) read and write permissions (rw) for all (a) users:
$ chmod a+rw letter.0610 $ ls -l letter.0610 -rw-rw-rw- 1 alex pubs 3355 May 2 10:52 letter.0610
Tip: You must have read permission to execute a shell script
Because a shell needs to read a shell script (a text file containing shell commands) before it can execute the commands within that script, you must have read permission for the file containing the script to execute it. You also need execute permission to execute a shell script directly on the command line. In contrast, binary (program) files do not need to be read; they are executed directly. You need only execute permission to run a binary (nonshell) program.
In the next example, chmod removes () read (r) and execute (x) permissions for users other (o) than the owner of the file (alex) and members of the group the file is associated with (pubs):
$ chmod o-rx check_spell $ ls -l check_spell -rwxr-x--- 2 alex pubs 852 May 5 14:03 check_spell
In addition to a (all) and o (other), you can use g (group) and u (user, although user refers to the owner of the file who may or may not be the user of the file at any given time) in the argument to chmod. You can also use absolute, or numeric, arguments with chmod. Refer to page 273 for more information on using chmod to make a file executable and to the chmod man page for information on absolute arguments and chmod in general. Refer to page 451 for more information on groups.
The Linux file access permission scheme lets you give other users access to the files you want to share yet keep your private files confidential. You can allow other users to read from and write to a file (handy if you are one of several people working on a joint project). You can allow others only to read from a file (perhaps a project specification you are proposing). Or you can allow others only to write to a file (similar to an inbox or mailbox, where you want others to be able to send you mail but do not want them to read your mail). Similarly you can protect entire directories from being scanned (covered shortly).
Tip: chmod: o for other, u for owner
When using chmod, many people assume that the o stands for owner; it does not. The o stands for other, whereas u stands for owner (user). The acronym UGO (user-group-other) can help you remember how permissions are named.
There is an exception to the access permissions just described. Anyone who knows the root password can log in as Superuser (page 391) and gain full access to all files, regardless of the file's owner or access permissions.
Setuid and Setgid Permissions
When you execute a file that has setuid (set user ID) permission, the process executing the file takes on the privileges of the file's owner. For example, if you run a setuid program that removes all files in a directory, you can remove files in any of the file owner's directories, even if you do not normally have permission to do so.
Security: Minimize use of setuid and setgid programs owned by root
Executable files that are setuid and owned by root have Superuser privileges when they are run, even if they are not run by root. This type of program is very powerful because it can do anything that Superuser can do (and that the program is designed to do). Similarly executable files that are setgid and belong to the group root have extensive privileges.
Because of the power they hold and their potential for destruction, it is wise to avoid indiscriminately creating and using setuid and setgid programs owned by or belonging to the group root. Because of their inherent dangers, many sites minimize the use of these programs on their systems. One necessary setuid program is passwd. See page 393 for a tip on setuid files owned by root and page 399 for a command that lists setuid files on the local system.
In a similar manner, setgid (set group ID) permission means that the process executing the file takes on the privileges of the group the file is associated with. The ls utility shows setuid permission by placing an s in the owner's executable position and setgid permission by placing an s in the group's executable position:
$ ls -l program1 -rwxr-xr-x 1 alex pubs 15828 Nov 5 06:28 program1 $ chmod u+s program1 $ ls -l program1 -rwsr-xr-x 1 alex pubs 15828 Nov 5 06:28 program1 $ chmod g+s program1 $ ls -l program1 -rwsr-sr-x 1 alex pubs 15828 Nov 5 06:28 program1
Security: Do not write setuid shell scripts
Never give shell scripts setuid permission. Several techniques for subverting them are well known.
Directory Access Permissions
Access permissions have slightly different meanings when they are used with directories. Although the three types of users can read from or write to a directory, the directory cannot be executed. Execute access permission is redefined for a directory: It means that you can cd into the directory and/or examine files that you have permission to read from in the directory. It has nothing to do with executing a file.
When you have only execute permission for a directory, you can use ls to list a file in the directory if you know its name. You cannot use ls without an argument to list the entire contents of the directory. In the following exchange, Jenny first verifies that she is logged in as herself. Then she checks the permissions on Alex's info directory. You can view the access permissions associated with a directory by running ls with the d (directory) and l (long) options:
$ who am i jenny pts/7 Aug 21 10:02 $ ls -ld /home/alex/info drwx-----x 2 alex pubs 512 Aug 21 09:31 /home/alex/info $ ls -l /home/alex/info ls: /home/alex/info: Permission denied
The d at the left end of the line that ls displays indicates that /home/alex/info is a directory. Alex has read, write, and execute permissions; members of the pubs group have no access permissions; and other users have execute permission only, as indicated by the x at the right end of the permissions. Because Jenny does not have read permission for the directory, the ls l command returns an error.
When Jenny specifies the names of the files she wants information about, she is not reading new directory information but rather searching for specific information, which she is allowed to do with execute access to the directory. She has read permission for notes so she has no problem using cat to display the file. She cannot display financial because she does not have read permission for it:
$ ls -l /home/alex/info/financial /home/alex/info/notes -rw------- 1 alex pubs 34 Aug 21 09:31 /home/alex/info/financial -rw-r--r-- 1 alex pubs 30 Aug 21 09:32 /home/alex/info/notes $ cat /home/alex/info/notes This is the file named notes. $ cat /home/alex/info/financial cat: /home/alex/info/financial: Permission denied
Next Alex gives others read access to his info directory:
$ chmod o+r /home/alex/info
When Jenny checks her access permissions on info, she finds that she has both read and execute access to the directory. Now ls l works just fine without arguments, but she still cannot read financial. (This restriction is an issue of file permissions, not directory permissions.) Finally, Jenny tries to create a file named newfile by using touch. If Alex were to give her write permission to the info directory, Jenny would be able to create new files in it:
$ ls -ld /home/alex/info drwx---r-x 2 alex pubs 512 Aug 21 09:31 /home/alex/info $ ls -l /home/alex/info total 8 -rw------- 1 alex pubs 34 Aug 21 09:31 financial -rw-r--r-- 1 alex pubs 30 Aug 21 09:32 notes $ cat /home/alex/info/financial cat: financial: Permission denied $ touch /home/alex/info/newfile touch: cannot touch '/home/alex/info/newfile': Permission denied
|Working with Directories