4.13.1. What Permissions Mean

Permissions refer to the ways in which someone can use a file. There are three such permissions under Unix:

• Read permission means you can look at the file's contents.

• Write permission means you can change or delete the file.

• Execute permission means you can run the file as a program.

When each file is created, the system assigns some default permissions that work most of the time. For instance, it gives you both read and write permission, but most of the world has only read permission. If you have a reason to be paranoid, you can set things up so that other people have no permissions at all.

Additionally, most utilities know how to assign permissions. For instance, when the compiler creates an executable program, it automatically assigns executable permission. When you check a file out of the revision control system (RCS) without locking it, you get only read permission (because you're not expected to change the file), but if you lock the file, you get read and write permission (you're expected to edit it and check it back in). We'll discuss RCS in the section "Section 14.2.7, "Revision Control Tools--RCS"" in Chapter 14, "Tools for Programmers".

There are times when defaults don't work, though. For instance, if you create a shell script or Perl program, you'll have to assign executable permission yourself so that you can run it. We'll show how to do that later in this section, after we get through the basic concepts.

Permissions have different meanings for a directory:

• Read permission means you can list the contents of that directory.

• Write permission means you can add or remove files in that directory.

• Execute permission means you can list information about the files in that directory.

Don't worry about the difference between read and execute permission for directories; basically, they go together. Assign both, or neither.

Note that, if you allow people to add files to a directory, you are also letting them remove files. The two privileges go together when you assign write permission. However, there is a way you can let users share a directory and keep them from deleting each other's files. See the section "Section 7.2.3, "Upgrading Other Software"" in Chapter 7, "Upgrading Software and the Kernel".

There are more files on Unix systems than the plain files and directories we've talked about so far. These are special files (devices), sockets, symbolic links, and so forth--each type observing its own rules regarding permissions. But you don't need to know the details on each type.

4.13.2. Owners and Groups

Now, who gets these permissions? To allow people to work together, Unix has three levels of permission: owner, group, and other. The "other" covers everybody who has access to the system and who isn't the owner or a member of the group.

The idea behind having groups is to give a set of users, like a team of programmers, access to a file. For instance, a programmer creating source code may reserve write permission to herself, but allow members of her group to have read access through a group permission. As for "other," it might have no permission at all. (You think your source code is that good?)

Each file has an owner and a group. The owner is generally the user who created the file. Each user also belongs to a default group, and that group is assigned to every file the user creates. You can create many groups, though, and assign each user to multiple groups. By changing the group assigned to a file, you can give access to any collection of people you want. We'll discuss groups more when we get to the section "Section 5.7.4, "The Group File"" in Chapter 5, "Essential System Management".

Now we have all the elements of our security system: three permissions (read, write, execute) and three levels (user, group, other). Let's looks at some typical files and see what permissions are assigned.

Figure 4-2 shows a typical executable program. We generated this output by executing ls with the -l option.

Figure 4-2. Displaying ownership and permissions

Two useful facts stand right out: the owner of the file is an author of this book and your faithful guide, mdw, while the group is lib (perhaps a group created for programmers working on libraries). But the key information about permissions is encrypted in the set of letters on the left side of the display.

The first character is a hyphen, indicating a plain file. The next three bits apply to the owner; as we would expect, mdw has all three permissions. The next three bits apply to members of the group: they can read the file (not too useful for a binary file) and execute it, but they can't write to it because the field that should contain a w contains a hyphen instead. And the last three bits apply to "other"; they have the same permissions in this case as the group.

As another exercise, here is a file checked out of RCS for editing:

-rw-r--r--   2 mdw      lib           878 Aug  7 19:28 tools.tex

The only difference between this file and that shown in Figure 4-2 is that the x bits in this case have been replaced by hyphens. No one needs to have execute permission because the file is not meant to be executed; it's just text.

One more example--a typical directory:

drwxr-xr-x   2 mdw      lib           512 Jul 17 18:23 perl

The left-most bit is now a d, to show that this is a directory. The executable bits are back, because you want people to see the contents of the directory.

Files can be in some obscure states that aren't covered here; see the ls manual page for gory details. But now it's time to see how you can change ownership and permissions.