CHAPTER 15

Setting Ownership and Permissions

As a multi-user OS, Linux provides tools to help you secure your files against unwanted access—after all, you wouldn't want another user to accidentally (or intentionally) read personal files or even delete your files! Linux handles these tasks through two features of files and directories: their ownership and their permissions. Every file has an associated owner (that is, an account with which it's linked), and also an associated group. Three sets of permissions define what the file's owner, members of the file's group, and all other users can do with the file. Thus, ownership and permissions are intertwined, although you use different text-mode commands to manipulate them. (GUI tools often combine the two, as described in this chapter.)

• Setting ownership
• Setting permissions

Setting Ownership

Linux's security model is based on that of Unix, which was designed as a multiuser OS. This security model therefore assumes the presence of multiple users on the computer, and provides the means to associate individual files with the users who create them—that is, files have owners. You should thoroughly understand this concept, and with that understanding, you can change a file's ownership, using either a GUI file manager or a text-mode shell.

Ownership also applies to running programs (that is, processes). Most programs you run are tied to the account you used to launch them. This identity, in conjunction with the file's ownership and permissions, determines whether a program may modify a file.

Understanding Ownership

Chapter 13, “Understanding Users and Groups,” and Chapter 14, “Creating Users and Groups,” described Linux's system of accounts. These accounts are the basis of file ownership. Specifically, every file has an owner—an account with which it's associated. This association occurs by means of the account's user ID (UID) number. Every file is also associated with a group by means of a group ID (GID) number.

As described later, in the section “Setting Permissions,” access to the file is controlled by means of permissions that can be set independently for the file's owner, the file's group, and all other users of the computer. As root, you can change the owner and group of any file. The file's owner can also change the file's group, but only to a group to which the user belongs.

The same principles of ownership apply to directories as apply to files: directories have owners and groups. These can be changed by root or, to a more limited extent, by the directory's owner.

Setting Ownership in a File Manager

As described in Chapter 4, “Using Common Linux Programs,” a file manager enables you to manipulate files. You're probably familiar with file managers in Windows or Mac OS X. Linux's ownership and permissions are different from those of Windows, though, so you may want to know how to check on, and perhaps change, ownership features using a Linux file manager. As noted in Chapter 4, you have a choice of several file managers in Linux. Most are similar in broad strokes but differ in some details. In this section, I use Nautilus, the GNU Network Object Model Environment (GNOME) file manager, as an example.

If you want to change the file's owner, you must run Nautilus as root, but you can change the file's group to any group to which you belong as an ordinary user. The procedure to perform this task as root is as follows:

1. Launch a terminal window.
2. In the terminal window, type su to acquire root privileges.

   If you're using Ubuntu, you may instead need to use sudo to launch Nautilus.

3. In the terminal window, type nautilus to launch Nautilus. You can optionally include the path to the directory in which you want Nautilus to start up. If you don't include a path, Nautilus will begin by displaying the contents of the /root directory.

   The /root directory is the root account's home directory.

4. Locate the file whose ownership you want to adjust and right-click it.
5. In the resulting menu, select Properties. The result is a Properties dialog box.
6. In the Properties dialog box, click the Permissions tab. The result resembles Figure 15.1.
7. To change the file's owner, select a new owner in the Owner field. This action is possible only if you run Nautilus as root.
8. To change the file's group, select a new group in the Group field. If you run Nautilus as an ordinary user, you will be able to select any group to which you belong, but if you run Nautilus as root, you will be able to select any group.
9. When you've adjusted the features you want to change, click Close.

If you want to change a file's group but not its owner, and if you're a member of the target group, you can launch Nautilus as an ordinary user. You can then pick up the preceding procedure at step 4.

FIGURE 15.1 Linux file managers give you access to the file's ownership and permission metadata.

You should be extremely cautious about running Nautilus as root. If you forget you're running this program as root, you can easily create new files as root, which will require additional root-privilege actions to correct by changing file ownership. It's also easy to accidentally delete critical system files as root that you could not delete as an ordinary user. For these reasons, I recommend that you use a text-mode shell to adjust file ownership. The change in the prompt makes it easier to notice you're running as root, and if you're used to using a GUI, you're less likely to launch additional programs as root from a text-mode shell than from Nautilus.

Setting Ownership in a Shell

The command to change the ownership of a file in the preferred text-mode manner is chown. In its most basic form, you pass it the name of a file followed by a username:

# chown bob targetfile.odf

This example gives ownership of targetfile.odf to bob. You can change the file's principal owner and its group with a single command by separating the owner and group with a colon (:):

# chown bob:users targetfile.odf

This example gives ownership of targetfile.odf to bob and associates the file with the users group. To change the group without changing the owner, you can omit the owner, leaving the colon and group name:

$ chown:users targetfile.odf

Alternatively, you can use the chgrp command, which works in the same way but changes only the group and does not require the colon before the group name:

$ chgrp users targetfile.odf

Note that the commands used to change the owner require root privileges, whereas you can change the group as an ordinary user—but only if you own the file and belong to the target group.

The chown and chgrp commands both support a number of options that modify what they do. The most useful of these is -R (or --recursive), which causes a change in ownership of all the files in an entire directory tree. For instance, suppose that the user mary has left a company, and an existing employee, bob, must access her files. If mary's home directory was /home/mary, you might type:

# chown -R bob /home/mary

This command gives bob ownership of the /home/mary directory, all the files in the /home/mary directory, including all its subdirectories, the files in the subdirectories, and so on. To make the transition a bit easier for bob, you might also want to move mary's former home directory into bob's home directory.

Setting Permissions

File ownership is meaningless without some way to specify what particular users can do with their own or other users' files. That's where permissions enter the picture. Linux's permission structure is modeled after that of Unix, and it requires a bit of explanation before you tackle the issue. Once you understand the basics, you can begin modifying permissions, using either a GUI file manager or a text-mode shell. You can also set default permissions for new files you create.

Understanding Permissions

To understand Unix (and hence Linux) permissions, you may want to begin with the display created by the ls command, which lists the files in a directory, in conjunction with its -l option, which creates a long directory listing that includes files' permissions. For instance, to see a long listing of the file test, you might type:

$ ls -l test
-rwxr-xr-x 1 rodsmith users 111 Apr 13 13:48 test

This line consists of several sections, which provide assorted pieces of information on the file:

Permissions The first column (-rwxr-xr-x in this example) is the file's permissions, which are of interest at the moment.

Number of links The next column (1 in this example) shows the number of hard links to the file—that is, the number of unique filenames that may be used to access the file.

Username The next column (rodsmith in this example) identifies the file's owner by username.

Group name The file's group (users in this example) appears next.

File size This example file's size is quite small—111 bytes.

Time stamp The time stamp (Apr 13 13:48 in this example) identifies the time the file was last modified.

Filename Finally, ls -l shows the file's name—test in this example.

The string that begins this output (-rwxr-xr-x in this example) is a symbolic representation of the permissions string. Figure 15.2 shows how this string is broken into four parts:

FIGURE 15.2 A symbolic representation of file permissions is broken into four parts.

The file type code The first character is the file type code, which represents the file's type, as summarized in Table 15.1. This type character is sometimes omitted from descriptions when the file type is not relevant or when it's identified in some other way.

Owner permissions These permissions determine what the file's owner can do with the file.

Group permissions These permissions determine what members of the file's group (who aren't its owner) can do with the file.

World (or “other”) permissions These permissions determine what users who aren't the file's owner or members of its group can do with the file

TABLE 15.1 Linux file type codes

In each of the three sets of permissions, the string identifies the presence or absence of each of three types of access: read, write, and execute. Read and write permissions are fairly self-explanatory. If the execute permission is present, it means that the file may be run as a program. The absence of the permission is denoted by a dash (-) in the permission string. The presence of the permission is indicated by the letter r for read, w for write, or x for execute.

Thus, the example permission string -rwxr-xr-x means that the file is a normal data file and that its owner, members of the file's group, and all other users can read and execute the file. Only the file's owner has write permission to the file.

Another representation of permissions is possible. It's compact but a bit confusing: It takes each of the three permissions groupings of the permission string (omitting the file type code) and converts it into a number from 0 to 7 (that is, a base 8 or octal number). The result is a three-digit octal number. Each number is constructed by starting with a value of 0 and then:

• Adding 4 if read permissions are present
• Adding 2 if write permissions are present
• Adding 1 if execute permissions are present

The resulting three-digit code represents permissions for the owner, the group, and the world. Table 15.2 shows some examples of common permissions and their meanings.

TABLE 15.2 Example permissions and their interpretations

Several special cases apply to permissions:

Directory execute bits Directories use the execute bit to grant permission to search the directory. This is a highly desirable characteristic for directories, so you'll almost always find the execute bit set when the read bit is set.

Directory write permissions Directories are files that are interpreted in a special way. As such, if a user can write to a directory, that user can create, delete, or rename files in the directory, even if the user isn't the owner of those files and does not have permission to write to those files.

Symbolic links Permissions on symbolic links are always 777 (rwxrwxrwx, or lrwxrwxrwx, to include the file type code). This access applies only to the link file itself, not to the linked-to file. In other words, all users can read the contents of the link to discover the name of the file to which it points, but the permissions on the linked-to file determine its file access. Changing the permissions on a symbolic link affects the linked-to file.

root Many of the permission rules don't apply to root. The superuser can read or write any file on the computer—even files that grant access to nobody (that is, those that have 000 permissions). The superuser still needs an execute bit set to run a program file.

Setting Permissions in a File Manager

The procedure for setting permissions in a file manager is similar to that for setting the ownership of a file:

• You normally adjust these settings using the same dialog box used to adjust ownership, such as the Nautilus dialog box shown earlier in Figure 15.1.
• You don't need to be root to adjust the permissions of files you own.
• You should use root access for this job only on files you don't own.

As seen in Figure 15.1, there are three Access items, associated with the Owner, the Group, and Others:

• The Owner item provides two options: Read-Only and Read and Write.
• The Group and Others items both provide Read-Only and Read and Write plus the None option. You can use these options to set the read and write permission bits on your file.

Nautilus requires setting the execute bit separately, by checking the Allow Executing File As Program box. This check box sets all three execute permission bits; you can't control execute permission more precisely with Nautilus. You also can't adjust the execute permissions on directories with Nautilus.

Setting Permissions in a Shell

In a text-mode shell, you can use chmod to change permissions. This command is rather complex, mostly because of the complex ways that permissions may be changed. You can specify the permissions in two forms: as an octal number or in a symbolic form, which is a set of codes related to the string representation of the permissions.

The octal representation of the mode is the same as that described earlier and summarized in Table 15.2. For instance, to change permissions on report.tex to rw-r--r--, you can issue the following command:

$ chmod 644 report.tex

A symbolic mode, by contrast, consists of three components:

• A code indicating the permission set you want to modify—u for the user (that is, the owner), g for the group, o for other users, and a for all permissions
• A symbol indicating whether you want to add (+), delete (-), or set the mode equal to (=) the stated value
• A code specifying what the permission should be, such as the common r, w, or x symbols, or various others for more advanced operations

Using symbolic modes with chmod can be confusing, so I don't describe them fully here; however, you should be familiar with a few common types of use, as summarized in Table 15.3. Symbolic modes are more flexible than octal modes because you can specify symbolic modes that modify existing permissions, such as adding or removing execute permissions without affecting other permissions. You can also set only the user, group, or world permissions without affecting the others. With octal modes, you must set all three permission bits equal to a value that you specify.

TABLE 15.3 Examples of symbolic permissions with chmod

Setting the umask

The user mask, or umask, determines the default permissions for new files. The umask is the value that is removed from 666 (rw-rw-rw-) permissions when creating new files, or from 777 (rwxrwxrwx) when creating new directories. For instance, if the umask is 022, then files will be created with 644 permissions by default, and new directories will have 755 permissions. Note that the removal operation is not a simple subtraction but a bitwise removal. That is, a 7 value in a umask removes the corresponding rwx permissions; but for files, for which the starting point is rw-, the result is --- (0), not −1 (which is meaningless).

You can adjust the umask with the umask command, which takes the umask value, as in umask 022. Typically, this command appears in a system configuration file, such as /etc/profile, or in a user configuration file, such as ~/.bashrc.