 |  |
| |
Regardless of how much you think you know about file permissions, there's always something new to learn.
There are three basic attributes for plain file permissions: read, write, and execute. Read and write permission obviously let you read the data from a file or write new data to the file. When you have execute permission, you can use the file as a program or shell script. The characters used to describe these permissions are r, w, and x, for execute.
Directories use these same permissions, but they have a different meaning. If a directory has read permission, you can see what files are in the directory. Write permission means you can add, remove, or rename files in the directory. Execute allows you to use the directory name when accessing files inside that directory. (Section 10.2 has more information about what's in a directory.) Let's examine this more closely.
Suppose you have read access to a directory but don't have execute access to the files contained in it. You can still read the directory, or inode information for that file, as returned by the stat(2) system call. That is, you can see the file's name, permissions, size, access times, owner and group, and number of links. You just cannot read the contents of the file.
Write permission in a directory allows you to change the contents in it. Because the name of the file is stored in the directory and not the file, write permission in a directory allows creation, renaming, or deletion of files. To be specific, if someone has write permission to your home directory, they can rename or delete your .login file and put a new file in its place. The permissions of your .login file do not matter in this regard. Someone can rename a file even if they can't read the contents of a file. (See Section 50.9.)
Execute permission on a directory is sometimes called search permission. If a directory gives you execute but not read permission, you can use any file in that directory; however, you must know the name. You cannot look inside the directory to find out the names of the files. Think of this type of directory as a black box. You can throw filenames at this directory, and sometimes you find a file, sometimes you don't. (See Section 50.10.)
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.
% ls -l drwxr-xr-x 3 jerry books 512 Feb 14 11:31 manpages -rw-r--r-- 1 jerry books 17233 Dec 10 2001 misc.Z -rwxr-xr-x 1 tim books 195 Mar 29 18:55 myhead
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:
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.)
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.
The files are managed by a team of people. This means group-write permission, or directories with the mode 775.
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:
alias proj "cd /usr/projects/proj;umask 002"
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.
-- BB
|  | |
| 50. File Security, Ownership, and Sharing |  | 50.3. Who Will Own a New File? |
Copyright © 2003 O'Reilly & Associates. All rights reserved.