Working with File Permissions

As you have seen in examples throughout the book, UNIX treats all directories as files; they have their own size (independent of their contents), their own permissions strings, and more. As a result, unless it's an important difference, from here on I talk about files with the intention of referring to files and directories both. Logic will confirm whether commands can apply to both, or to files only, or to directories only. (For example, you can't edit a directory and you can't store files inside other files.)

Task 5.1: Understanding File Permissions Settings

In the past hour you learned a bit about how to interpret the information that ls offers on file permissions when ls is used with the -l flag. Consider the following example:

						% ls -l
total 403
drwx------  2 taylor        512 Sep 30 10:38 Archives/
drwx------  3 taylor        512 Oct  1 08:23 InfoWorld/
-rw-------  1 taylor     106020 Oct 10 13:47 LISTS
drwx------  2 taylor       1024 Sep 30 10:50 Mail/
drwx------  2 taylor        512 Oct  6 09:36 News/
drwx------  2 taylor        512 Sep 30 10:51 OWL/
-rw-------  1 taylor       4643 Oct 10 14:01 RUMORS.18Sept
drwx------  2 taylor        512 Oct 10 19:09 bin/
-rw-------  1 taylor       3843 Oct 10 16:22 iecc.list
-rw-rw-r--  1 taylor     280232 Oct 10 16:22 mailing.lists
-rw-rw----  1 taylor       1031 Oct  7 15:44 newlists
drwx------  2 taylor        512 Oct 10 19:09 src/

The first item of information on each line is what is key here. You learned in the preceding hour that the first item is called the permissions string or, more succinctly, permissions. It also is sometimes referred to as the mode or permissions mode of the file, a mnemonic that can be valuable for remembering how to change permissions.

The permissions can be broken into four parts: type, owner, group, and world permissions. The first character indicates the file type: d is a directory and - is a regular file. There are various other types of files in UNIX, each indicated by the first letter of its permissions string, as summarized in Table 5.1. You can safely ignore, however, any file that isn't either a regular file or a directory.

The next nine letters in the permissions string are broken into three groups of three each—representing the owner, group, and everyone else—as shown in Figure 5.1.

To understand what the permissions actually mean to the computer system, remember that UNIX treats everything as a file. If you install an application, it's just like everything else, with one exception: The system knows that an application is executable. A letter to your Mum is a regular file, but if you were to tell UNIX that it was executable, the system would merrily try to run it as a program (and fail).

There are three primary types of permission for files: read, write, and execute. Read permission enables users to examine the contents of the file with various programs, but they cannot alter, modify, or delete any information. They can copy the file to a directory where they have write permission and then edit the new version.

Write permission is the next step up. Users with write access to a file can add information to the file. If you have write permission and read permission for a file, you can edit the file—the read permission enables you to view the contents, and the write permission enables you to alter them. With write permission only, you'd be able to add information to the file, but you wouldn't be able to view the contents of the file at any time. Admittedly, write-only permission is unusual in UNIX, but you might see it for log files, which are files that track activity on the system. Imagine if each time anyone logged in to your UNIX system the computer recorded the fact, noting who logged in, where they logged in from, and the current time and date. Armed with that information, you could ascertain who last logged in, who uses dial-up phone lines, and who uses the computer the most. (In fact, there's a UNIX command that does just that. It's called last.)

So far you've learned that you can have files with read-only permission, read-write permission, and write-only permission. The third type of access permission is execute, noted by ls with an x in the third slot of the permissions string. You can set any file to be executable; shell scripts, perl, and other interpreted languages are text files that are executed.

						% ls -l bin
total 57
-rwx------  1 taylor       1507 Aug 17 13:27 bounce.msg
-rwxrwx---  1 taylor      32916 Oct 10 19:09 calc
-rwx------  1 taylor      18567 Sep 14 22:14 fixit
-rw-------  1 taylor        334 Oct  1 09:53 punt
-rwx------  1 taylor       3424 Sep 10 22:27 rumor.mill.sh

If you're using the C Shell as your command interpreter, it probably won't find the new command you just created. This is because, to speed things up, it keeps an internal table of where different commands are found in your search path. You need to force the program to rebuild its table, and you can do that with the simple command rehash. If, when you enter the filename, you don't get permission denied but instead see Command not found, enter rehash and try again.

Execute permission enables the user to run the file as if it were a program. Execute permission is independent of other permissions granted—or denied—so it's perfectly feasible to have a program with read and execute permission, but no write permission. (After all, you wouldn't want others altering the program itself.) You also can have programs with execute permission only. This means that users can run the application, but they can't examine it to see how it works or copy it. (Copying requires the ability to read the file.)

Though actual programs with execute-only permission work fine, a special class of programs called shell scripts fail. Shell scripts act like a UNIX command-line macro facility, which enables you to easily save a series of commands in a file and then run them as a single program. To work, however, the shell must be able to read the file and execute it too, so shell scripts always require both read and execute permission.

There are clearly quite a few permutations on the three different permissions: read, write, and execute. In practice, there are a few that occur most commonly, as listed in Table 5.2.

These permissions have different meanings when applied to directories, but --- always indicates that no one can access the file in question.

Interpretation of the following few examples should help:

-rw-------  1 taylor       3843 Oct 10 16:22 iecc.list
-rw-rw-r--  1 taylor     280232 Oct 10 16:22 mailing.lists
-rw-rw----  1 taylor       1031 Oct  7 15:44 newlists
-rwxr-x---  1 taylor         64 Oct  9 09:31 the.script

The first file, iecc.list, has read and write permission for the owner (taylor) and is off-limits to all other users. The file mailing.lists offers similar access to the file owner (taylor) and to the group, but offers read-only access to everyone else on the system. The third file, newlists, provides read and write access to both the file owner and group, but no access to anyone not in the group.

The fourth file on the list, the.script, is a program that can be run by both the owner and group members, read (or copied) by both the owner and the group, and written (altered) by the owner. In practice, this probably would be a shell script, as described earlier, and these permissions would enable the owner (taylor) to use an editor to modify the commands therein. Other members of the group could read and use the shell script but would be denied access to change it.

Task 5.2: Directory Permissions Settings

Directories are similar to files in how you interpret the permissions strings. The differences occur because of the unique purpose of directories, namely to store other files or directories. I always think of directories as bins or boxes. You can examine the box itself, or you can look at what's inside.

In many ways, UNIX treats directories simply as files in the file system, where the content of the file is a list of the files and directories stored within, rather than a letter, program, or shopping list.

The difference, of course, is that when you operate with directories, you're operating both with the directory itself and, implicitly, with its contents. By analogy, when you fiddle with a box full of toys, you're not altering just the state of the box itself, but also potentially the toys within.

Three permissions are possible for a directory, just as for a file: read, write, and execute. The easiest is write permission. If a directory has write permission enabled, you can add new items and remove items from the directory. It's like owning the box; you can do what you'd like with the toys inside.

The interaction between read and execute permission with a directory is confusing. There are two types of operations you perform on a directory: listing the contents of the directory (usually with ls) and examining specific known files within the directory.

Permissions of files and directories will prove easier as you work with UNIX more.

Task 5.3: Modifying File and Directory Permissions with chmod

Now that you can list directory permissions and understand what they mean, how about learning a UNIX command that lets you change them to meet your needs? You've already had a sneak preview of the command: chmod. The mnemonic is “change mode,” and it derives from early UNIX folk talking about permission modes of files. You can remember it by thinking of it as a shortened form of change permission modes.

To sound like a UNIX expert, pronounce chmod as “ch-mod,” “ch” like the beginning of child, and “mod” to rhyme with cod.

The chmod command enables you to specify permissions in two different ways: symbolically or numerically. Symbolic notation is most commonly used to modify existing permissions, whereas numeric format always replaces any existing permission with the new value specified. In this task, you learn about symbolic notation, and the next task focuses on the powerful numeric format.

Symbolic notation for chmod is a bit like having a menu of different choices, enabling you to pick the combination that best fits your requirements. Figure 5.2 shows the menus.

The command chmod is like a smorgasbord where you can choose any combination of items from either the first or last boxes, and stick your choice from the center box between them.

For example, if you wanted to add write permission to the file test for everyone in your group, you would, working backward from that description, choose g for group, + for add, and w for write. The finished UNIX command would be chmod g+w test.

When you have an account assigned to you, you have a unique user name, but you are also included in one or more groups. Group permissions let other people working on the same project share information without opening up the information to the rest of the world.

If you decided to take away read and execute permission for everyone not in your group, you could use chmod o-rx test to accomplish the task.

Permissions in UNIX are based on a concentric access model from Multics. (In Hour 1, “What Is This UNIX Stuff?” you learned that the name UNIX is also a pun on Multics.) Figure 5.3 illustrates this concept.

As a result, it's incredibly rare to see a file where the owner doesn't have the most access to a file. It'd be like buying a car and letting everyone but yourself drive it—rather silly. Similarly, members of the group are given better or equal permission to everyone else on the machine. You would never see r--r--rwx as a permissions string.

Experiment a bit more with the various combinations possible with the chmod symbolic notation. How would you change permission on a directory to enable all users to use ls to examine it but to deny them the ability to add or remove files? How about adding write access for the owner but removing it for everyone else?

Task 5.4: Setting New File Permissions with chmod

The second form of input that chmod accepts is absolute numeric values for permissions. Before you can learn how to use this notation, you have to learn a bit about different numbering systems first.

The numbering system you're familiar with, the one you use to balance your checkbook and check the receipt from the market, is decimal, or base 10. This means that each digit—from right to left—has the value of the digit raised by a power of 10, based on the digit's location in the number. Figure 5.4 shows what the number 5,783 is in decimal.

You can see that in a base-10 numbering system, the value of a number is the sum of the value of each digit multiplied by the numeric base raised to the nth power. The n is the number of spaces the digit is away from the rightmost digit. That is, in the number 5,783, you know that the 7 is worth more than just 7, because it's two spaces away from the rightmost digit (the 3). Therefore, its value is the numeric base (10) raised to the nth power, where n is 2 (it's two spaces away). Ten to the second power equals 100 (102 = 100), and when you multiply that by 7, sure enough, you find that the 7 is worth 700 in this number.

What does all this have to do with the chmod command? At its most fundamental, UNIX permissions are a series of on/off switches. Does the group have write permission? One equals yes, zero equals no. Each digit in a decimal system can have 10 different values. A binary system is one in which each digit can have only two values: on or off, 1 or 0, yes or no. Therefore, you can easily and uniquely describe any permissions string as a series of zeros and ones, as a binary number. Figure 5.5 demonstrates.

The convention is that if a letter is present, the binary digit is a 1—that permission is permitted—and if no letter is present, the digit is a zero. Thus, r-xr----- can be described as 101100000, and r--r--r-- can be described in binary as 100100100.

You've already learned that the nine-character permissions string is really just a three-character permissions string duplicated thrice for the three different types of user (the owner, group, and everyone else). That means that you can focus on learning how to translate a single tri-character permissions substring into binary and extrapolate for more than one permission. Table 5.4 lists all possible permissions and their binary equivalents.

Knowing how to interpret decimal numbers using the rather complex formula presented earlier, you should not be surprised that the decimal equivalent of any binary number can be obtained by the same technique. Figure 5.6 shows how, with the binary equivalent of the r-x permission.

If r-x is equal to 5, it stands to reason that each of the possible three-character permissions has a single-digit equivalent, and Table 5.5 expands Table 5.4 to include the single-digit equivalents.

The value of having a single digit to describe any of the seven different permission states should be obvious. Using only three digits, you now can fully express any possible combination of permissions for any file or directory in UNIX—one digit for the owner permission, one for group, and a one for everyone else. Figure 5.7 shows how to take a full permissions string and translate it into its three-digit numeric equivalent.

From this illustration, you can see how the permissions string rw-r----- (read and write permission for the owner, read permission for the group, and no access allowed for everyone else) is exactly equivalent to the numeric string 640.

There's one last step required before you can try using the numeric permissions strings with chmod. You need to be able to work backward to determine a permission that you'd like to set, and figure out the numeric equivalent for that permission.

Task 5.5: Calculating Numeric Permissions Strings

For example, if you wanted to have a directory set so that you have all access, people in your group can look at the contents but not modify anything, and everyone else is shut out, how would you do it?

All permissions for yourself means you want read+write+execute for owner (or numeric permission 7); read and listing permission for others in the group means read+execute for group (numeric permission 5); and no permission for everyone else, numeric permission 0. Put the three together and you have the answer, 750.

That's the trick of working with chmod in numeric mode. You specify the absolute permissions you want as a three-digit number, and the system sets the permissions on the file or directory appropriately.

The absolute concept is important with this form of chmod. You cannot use the chmod numeric form to add or remove permissions from a file or directory. It is usable only for reassigning the permissions string of a file or directory.

The good news is that, as you learned earlier in this hour, there is a relatively small number of commonly used file permissions, summarized in Table 5.6.

You've looked at both the numeric mode and the symbolic mode for defining permissions. Having learned both, which do you prefer?

Somehow I've never gotten the hang of symbolic mode, so I almost always use the numeric mode for chmod. The only exception is when I want to add or delete simple permissions. Then, I use something like chmod +r test to add read permission. Part of the problem is that I don't think of the user of the file but rather the owner, and specifying o+r causes chmod to change permission for others. It's important, therefore, that you remember that files have users so you remember u for user, and that everyone not in the group is other so you remember o. Otherwise, learn the numeric shortcut!

File permissions and modes are one of the most complex aspects of UNIX. You can tell—it's taken two hours to explain it fully. It's very important that you spend the time really to understand how the permissions strings relate to directory permissions, how to read the output of ls, and how to change modes using both styles of the chmod command. It'll be time well spent.

Task 5.6: Establishing Default File and Directory Permissions with the umaskCommand

When I've created files, they've had read+write permission for the owner and group, but no access allowed for anyone else. When you create files on your system, you might find that the default permissions are different.

The controlling variable behind the default permissions is called the file creation mask, or umask for short.

Inexplicably, umask doesn't always list its value as a three-digit number, but you can find its value in the same way you figured out the numeric permissions strings for chmod. For example, when I enter umask, the system indicates that my umask setting is 07. A leading zero has been dropped, so the actual value is 007, a value that British MI6 could no doubt appreciate!

But 007 doesn't mean that the default file is created with read+write+execute for everyone else and no permissions for the owner or group. It means quite the opposite, literally.

The umask command is a filter through which permissions are pushed to ascertain what remains. Figure 5.8 demonstrates how this works.

Think of your mask as a series of boxes: If the value is true, the information can't exude through the box. If the value is false, it can. Your mask is therefore the direct opposite to how you want your permissions to be set. In Figure 5.8, I want to have 770 as the default permission for any new file or directory I create, so I want to specify the exact opposite of that, 007. Sure enough, with this umask value, when I create new files, the default permission allows read and write access to the owner and group, but no access to anyone else.

Things are a bit trickier than that. You've probably already asked yourself, Why, if I have 007 as my mask (which results in 770 as the default permissions), do my files have 660 as the actual default permission?

The reason is that UNIX tries to be smart about the execute permission setting. If I create a directory, UNIX knows that execute permission is important, and so it grants it. However, for some files (particularly text files), execute permission doesn't make sense, so UNIX actually masks it out internally.

Another way to look at this is that any time you create a file containing information, the original mask that the system uses to compare against your umask is not 777 (not rwxrwxrwx, to put it another way) but rather 666 (rw-rw-rw-), in recognition of the unlikelihood that you'll want to execute the new file.

The good news is that you now know an easy way to set the execute permission for a file if the system gets it wrong: chmod +x filename does the trick.

As a rule of thumb, it's best to leave the execute permission enabled when building umask values so the system doesn't err when creating directories.

The umask is something set once and left alone. If you've tried various experiments on your computer, remember to restore your umask back to a sensible value to avoid future problems (though each time you log in to the system it's reset to your default value).

In the next hour, you learn how to use the mkdir command to create new directories, and you see how the umask value affects default directory access permissions.

Task 5.7: Identifying Owner and Group for Any File or Directory

One of the many items of information that the ls command displays when used with the -l flag is the owner of the file or directory. So far, all the files and directories in your home directory have been owned by you, with the probable exception of the “..” directory, which is owned by whomever owns the directory above your home.

In other words, when you enter ls -l, you should see your account name as the owner for every file in the listing.

If you're collaborating with another user, however, there might well be times when you'll want to change the owner of a file or directory once you've created and modified it.The first step in accomplishing this is to identify the owner and group.

Identifying the owner is easy; ls lists that by default. But how do you identify the group of which the file or directory is a part?

On many System V-based systems, the output of ls -l always shows user and group. The -g flag actually turns off this display!

Files and directories have both owners and groups, although the group is ultimately less important than the owner, particularly where permissions and access are involved.