 | Chapter 22 File Security, Ownership, and Sharing |  |
| Chapter 22 File Security, Ownership, and Sharing | |
[Think you know all about permissions? Even if you do, skim through this article. Bruce has some good tips. -JP]
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. (Article 18.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 you do not have execute access to the files in the directory. You can still read the directory, or inode (1.22) 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 cannot read the contents of the file.
Write permission in a directory allows you to change the contents of a directory. 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. Someone can rename a file even if they can't read the contents of a file. (See article 22.11.)
Execute permission on a directory is sometimes called search permission. If you found a directory that gave you execute permission, but not read permission, you could 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 article 22.12.)
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
group (22.13)
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:
[1]
[1] 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 -ldrwxr-xr-x 3 jerry books 512 Feb 14 11:31 manpages -rw-r--r-- 1 jerry books 17233 Dec 10 1990 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 (17.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 wanted to have a data file that you could 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. (Article 1.23 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 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 (1.24), 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 (22.14)
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 (22.7)
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 article 4.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.
What is needed is a mechanism to prevent any new file from having world-write access. This mechanism exists with the umask command (22.4). 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 (10.2) 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. Article 14.14 shows how.
Still another method is to run find (17.1) three times a day and search for files owned by you in the project directory that have the wrong permission:
$USER xargs chmod | % |
|---|
You can use the command crontab -e (40.15, 40.12) to define when to run this command. [If your system doesn't have personal crontabs, use a self-restarting at job (40.8). -JP ]
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 eight 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 (22.5) in the file permissions is used. If a disk partition is mounted without the Berkeley group mechanism, then 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.
-
|  | |
| 22.1 Introduction to File Ownership and Security |  | 22.3 Who Will Own a New File? |
