All files have an owner and group associated with them. There are three sets of read/write/execute permissions: one set for the user or owner of the file, one set for the group (Section 49.6) of the file, and one set for everyone else. These permissions are determined by nine bits in the inode information and are represented by the characters rwxrwxrwx in an ls -l listing:[134]

[134]On some Unix systems, ls -l produces an eight-column listing without the group name (here, books). Use ls -lg to get the listing format shown here.

The first character in the ls -l listing specifies the type of file (Section 9.13). The first three of the nine permissions characters that follow specify the user; the middle three, the group; and the last three, the world. If the permission is not true, a dash is used to indicate lack of privilege. If you want to have a data file that you can read or write but don't want anyone else to access, the permissions would be rw-------.

An easier way to specify these nine bits is with three octal digits instead of nine characters. (Section 1.17 has diagrams of permission bits and explains how to write permissions as an octal number.) The order is the same, so the above permissions can be described by the octal number 600. The first number specifies the owner's permission. The second number specifies the group's permission. The last number specifies permission to everyone who is not the owner or not in the group of the file [although permissions don't apply to the superuser (Section 1.18), who can do anything to any file or directory. -- JP].

This last point is subtle. When testing for permissions, the system looks at the groups in order. If you are denied permission, Unix does not examine the next group. Consider the case of a file that is owned by user jo, is in the group guests, and has the permissions -----xrwx, or 017 in octal. This has the result that user jo cannot use the file, anyone in group guests can execute the program, and everyone else besides jo and guests can read, write, and execute the program. This is not a very common set of permissions, but some people use a similar mechanism (Section 49.7) to deny one group of users from accessing or using a file. In the above case, jo cannot read or write the file she owns. She could use the chmod (Section 50.5) command to grant herself permission to read the file. However, if the file was in a directory owned by someone else, and the directory did not give jo read or search permission, she would not be able to find the file to change its permission.

The above example is an extreme case. Most of the time permissions fall into four cases:

1. The information is personal. Many people have a directory or two in which they store information they do not wish to be public. Mail should probably be confidential, and all of your mailbox files should be in a directory with permissions of 700, denying everyone but yourself and the superuser read access to your letters. (See Section 7.5.)

2. The information is not personal, yet no one should be able to modify the information. Most of my directories are set up this way, with the permissions of 755.

3. The files are managed by a team of people. This means group-write permission, or directories with the mode 775.

4. In the previous case, for confidential projects, you may want to deny access to people outside the group. In this case, make directories with mode 770.

You could just create a directory with the proper permissions and put the files inside the directory, hoping the permissions of the directory will "protect" the files in the directory. This is not adequate. Suppose you had a directory with permissions 755 and a file with permissions 666 inside the directory. Anyone could change the contents of this file because the world has search access on the directory and write access to the file.

Go to http://examples.oreilly.com/upt3 for more information on: umask.csh, umask.sh

What is needed is a mechanism to prevent any new file from having world-write access. This mechanism exists with the umask command. If you consider that a new directory would get permissions of 777, and that new files would get permissions of 666, the umask command specifies permissions to "take away" from all new files. To "subtract" world-write permission from a file, 666 must have 002 "subtracted" from the default value to get 664. To subtract group and world write, 666 must have 022 removed to leave 644 as the permissions of the file. These two values of umask are so common that it is useful to have some aliases (Section 49.4) defined:

alias open umask 002
alias shut umask 022

With these two values of umask, new directories will have permissions of 775 or 755. Most people have a umask value of one of these two values.

In a friendly work group, people tend to use the umask of 002, which allows others in your group to make changes to your files. Someone who uses the mask of 022 will cause grief to others working on a project. Trying to compile a program is frustrating when someone else owns files that you must delete but can't. You can rename files if this is the case or ask the system administrator for help.

Members of a team who normally use a default umask of 022 should find a means to change the mask value when working on the project (or else risk flames from your fellow workers!). Besides the open alias above, some people have an alias that changes directories and sets the mask to group-write permission:

This isn't perfect, because people forget to use aliases. You could have a special cd alias and a private shell file in each project directory that sets the umask when you cd there. Other people could have similar files in the project directory with different names. Section 31.13 shows how.

Still another method is to run find (Section 9.1) three times a day and search for files owned by you in the project directory that have the wrong permission:

$USERSection 35.5, xargsSection 28.17, chmodSection 50.5

% find /usr/projects -user $USER ! -perm -020 -print | \
xargs chmod g+w

You can use the command crontab -e (Section 25.2) to define when to run this command.

Since group-write permission is so important in a team project, you might be wondering how the group of a new file is determined. The answer depends on several factors. Before I cover these, you should note that Berkeley and AT&T-based systems would use different mechanisms to determine the default group.

Originally Unix required you to specify a new group with the newgrp command. If there was a password for this group in the /etc/group file, and you were not listed as one of the members of the group, you had to type the password to change your group.

Berkeley-based versions of Unix would use the current directory to determine the group of the new file. That is, if the current directory has cad as the group of the directory, any file created in that directory would be in the same group. To change the default group, just change to a different directory.

Both mechanisms had their good points and bad points. The Berkeley-based mechanism made it convenient to change groups automatically. However, there is a fixed limit of groups one could belong to. SunOS 4 has a limit of 16 groups. Earlier versions had a limit of 8 groups.

SunOS and System V Release 4 support both mechanisms. The entire disk can be mounted with either the AT&T or the Berkeley mechanism. If it is necessary to control this on a directory-by-directory basis, a special bit in the file permissions is used. If a disk partition is mounted without the Berkeley group mechanism, a directory with this special bit will make new files have the same group as the directory. Without the special bit, the group of all new files depends on the current group of the user.