Understanding Advanced Permissions

In Chapter 7, "Understanding File Properties," you learned the basics of file ownership and permissions in Linux. You also learned to use the chmod command at the command line to change file permissions using the symbols (letters) r, w, and x for read, write, and execute.

The basic set of read, write, and execute permissions and the basic file ownership behavior work well for most situations. However, Linux does provide a way for administrators to change the ownerships of existing files, as well as an additional set of permissions properties for more unique situations, which can provide finer-grained control over the ways in which files and directories behave.

Changing File Ownership

The chown command can be used to change the user and/or group ownership of an existing file. This capability can be useful if, for example, you want to make a file you created readable to other members of a group of which you are a member. By changing the file's group ownership and permissions, you can make the file readable by members of the group while remaining secure with regard to other users of the system.

To use the chown command to change ownership for an existing file or directory, call chown as follows:

 chown user.group file 

Replace user with the name of the user who should be given ownership of the file and group with the name of the group that should be given ownership of the file. Replace file with the name of the file whose ownership is to be changed. For example, to change the group ownership of a file called myfile.txt to the programmers group, you issue the following command:

 [you@workstation20 ~]$ chown you.programmers myfile.txt [you@workstation20 ~]$ 

Users Can't Change User Ownership

Normal users can't change user ownership. They can change only group ownershipand only to groups of which they are members.

The root user can change both user and group ownerships of any existing user account or group.

Using chmod in Numeric Mode

In Chapter 7, you learned that each file or directory in a Linux system is governed by three sets of read, write, and execute switches. When considered from left to right as they are usually written, these sets of switches belong to the file's owning user, the file's owning group, and everyone else, in that order. For example, the following permissions string represents a normal file that is readable, writable, and executable by everyone:

 -rwxrwxrwx 

In the symbolic mode of the chmod command, you use symbols such as u, g, o, r, w, and x arranged in various patterns as arguments to change these permissions. The numeric mode of chmod works somewhat differently. To call chmod in numeric mode, you use the following format:

 chmod NNN file 

Each N must be a numeric digit. The first N represents the permissions for the owning user of the file; the second N, for the owning group; and the third N, for everyone else. Each N has a value of zero (0) for no permissions or a single-digit sum created from the values in Table 31.1 to indicate the absolute permissions that are to be assigned.

Table 31.1. Permissions Values for chmod's Numeric Mode

Value	Meaning
4	Read permission is granted for this file or directory.
2	Write permission is granted for this file or directory.
1	Execute permission is granted for this file or directory.

For example, to assign full read, write, and execute permissions for all users to a file called myfile.txt, you enter the following:

 [you@workstation20 ~]$ chmod 777 myfile.txt [you@workstation20 ~]$ 

Table 30.2 shows a number of additional examples for numeric strings, which can be provided to chmod, and their symbolic meanings.

Table 30.2. Examples of Numeric Values for chmod and Resulting Permissions

Number	Permissions	Description
664	-rw-rw-r--	The owning user and owning group can read and write. Other users can only read.
444	-r--r--r--	All users anywhere can read. No other permissions are granted.
700	-rwx------	The owning user can read, write, and execute. No other permissions are granted.
750	-rwxr-x---	The owning user can read, write, and execute. The owning group can read and execute. No other permissions are granted.

Although the symbolic mode of chmod is typically preferred by beginners, most longtime Linux or Unix users prefer to use the numeric mode for its simplicity and brevity.

Understanding Special Permissions

As you use Linux, you will from time to time encounter several additional types of permissions values in the output of long directory listings. Understanding these special permissions is important because they significantly alter the way in which programs or directories behave:

• A letter s appearing in a file's user permissions' execute position indicates that when this program is run, it is granted access to files and system resources as though it had been called by its owning user, rather than by the user who actually called it. Files with this permission switch set are called SUID (Set User ID) executables.

• A letter s appearing in a file's group permissions' execute position indicates that when this program is run, it is granted access to files and system resources as though it had been called by a member of its owning group, rather than by the group of the user who actually called it. Files with this permission switch set are called SGID (Set Group ID) executables.

• A letter t appearing in the last position of a directory's permissions indicates that users who are allowed to write to this directory are allowed to remove only files or directories for which they are the owning user. This permission switch is known simply as the sticky bit.

The SUID and SGID bits are rarely used; the sticky bit is used more often, usually to create a public storage area in which users can create and remove their own files. You can assign the SUID, SGID, and sticky bits to file or directory permissions using chmod's numeric mode by including an extra digit at the beginning of the numeric permissions code supplied to chmod as an argument. The values used in this optional first digit are shown in Table 30.3.

Table 30.3. Codes Used to Assign Special Permissions with chmod

Value	Meaning
4	Assigns the SUID (Set User ID) property to this executable file
2	Assigns the SGID (Set Group ID) property to this executable file
1	Assigns the sticky bit to this directory

Table 30.4 provides some sample numeric codes for chmod that use special permissions, along with resulting descriptions.

Table 30.4. Special Permissions Examples Using chmod's Numeric Mode

Number	Permissions	Description
4754	-rwsr-xr--	The owning user can read, write, and execute. The owning group can read and execute. Everyone else can read. When this program is executed, its user permissions behave as though it were called by its owning user.
2754	-rwxr-sr--	The owning user can read, write, and execute. The owning group can read and execute. Everyone else can read. When this program is executed, its group permissions behave as though it were called by a member of its owning group.
6554	-r-sr-sr--	The owning user can read and execute. The owning group can read and execute. Everyone else can read. When this program is executed, its user permissions behave as though it were called by its owning user, and its group permissions behave as though it were called by a member of its owning group.
1777	drwxrwxrwt	All users can read, create files in, and delete files from this directory and can make this directory their current working directory. However, users can delete only files that they themselves own.

To assign the SUID or SGID properties to an executable file, you must be either the owner of the file or a member of the file's owning group, respectivelyor the root user. The SUID and SGID properties are rarely used.

Why Are SUID and SGID Important?

An understanding of the SUID and SGID properties is important for Linux security precisely because these properties are so potentially insecure: They allow users to transcend their account identities, which are fundamental to permissions. The SUID and SGID properties have been judiciously limited to a few programs such as su in Fedora Core 4. You should rarely, if ever, assign them yourself.

More importantly, you should be very suspicious of SUID or SGID files that have creation dates well after the date on which you installed Fedora Core 4. You should also be wary of SUID or SGID files that aren't in a binaries directory such as /sbin, /usr/bin, or /usr/sbin.

You can get a listing of all SUID and SGID binaries by using the following two find commands:

 find / -perm +2000 find / -perm +4000 

You should run these commands soon after you install your system and save the output; afterward, you should run them again periodically to check for the emergence of new SUID or SGID files. If such a file appears, use chmod to remove its executable permissions at once and refer to Chapter 35, "Backups, Troubleshooting, and Rescue."