| Protecting Data in AFS | ||
|---|---|---|
 | Chapter 14. Managing Access Control Lists |  |
| Protecting Data in AFS | ||
|---|---|---|
| | Chapter 14. Managing Access Control Lists | |
This section describes the main differences between the AFS and UFS file protection systems, discusses the implications of directory-level protections, and describes the seven access permissions.
The UFS mode bits data protection system and the AFS ACL system differ in the following ways:
Protection at the file level (UFS) versus the directory level (AFS)
UFS associates a set of nine mode bits with each file element, three (rwx) for each of the element's owner, owning group, and all other users. A similar set of mode bits on the file's directory applies to the file only in an oblique way.
An AFS ACL instead protects all files in a directory in the same way. If a certain file is more sensitive than others, store it in a directory with a more restrictive ACL.
Defining access at the directory level has important consequences:
The permissions on a directory's ACL apply to all of the files in the directory. When you move a file to a different directory, you effectively change the access permissions that apply to it to those on its new directory's ACL. Changing a directory's ACL changes the protection on all the files in it.
When you create a subdirectory, its initial ACL is created as a copy of its parent directory's ACL. You can then change the subdirectory's ACL independently. However, the parent directory's ACL continues to control access to the subdirectory in the following way: the parent directory's ACL must grant the l (lookup) permission to a user (or a group the user belongs to) in order for the user to access the subdirectory at all.
In general, then, it is best to assign fairly liberal access permissions to high-level directories (including user home directories). In particular, it often makes sense to grant at least the l permission to the system:anyuser or system:authuser group on high-level directories. For further discussion, see Using Groups on ACLs.
How the mode bits are interpreted
Mode bits are the only file-protection system in UFS. AFS allows you to set the UNIX mode bits on a file in addition to the ACL on its directory, but it interprets them differently. See How AFS Interprets the UNIX Mode Bits.
Three access permissions (UFS) versus seven (AFS)
UFS defines three access permissions in the form of mode bits: r (read), w (write), and x (execute). AFS defines seven permissions, which makes access control more precise. For detailed descriptions, see The AFS ACL Permissions.
| a (administer) |
| d (delete) |
| i (insert) |
| k (lock) |
| l (lookup) |
| r (read) |
| w (write) |
Three defined users and groups (UFS) versus many (AFS)
UFS controls access for one user and two groups by providing a set of mode bits for each: the user who owns the file or directory, a single defined group, and everyone who has an account on the system.
AFS, in contrast, allows you to place many entries (individual users or groups) on an ACL, granting a different set of access permissions to each one. The number of possible entries is about 20, and depends on how much space each entry occupies in the memory allocated for the ACL itself.
AFS defines two system groups, system:anyuser and system:authuser, which represent all users and all authenticated users, respectively; for further discussion, see Using Groups on ACLs. In addition, users can define their own groups in the Protection Database, consisting of individual users or machine IP addresses. Users who have the a permission on an ACL can create entries for the system groups as well as groups defined by themselves or other users. For information on defining groups, see Administering the Protection Database.
When a user requests access to a file or directory, the File Server sums together all of the permissions that the relevant ACL extends to the user and to groups to which the user belongs. Placing group entries on ACLs therefore can control access for many more users than the ACL can accommodate as individual entries.
Functionally, the seven standard ACL permissions fall into two groups: one that applies to the directory itself and one that applies to the files it contains.
The four permissions in this group are meaningful with respect to the directory itself. For example, the i (insert) permission does not control addition of data to a file, but rather creation of a new file or subdirectory.
This permission functions as something of a gate keeper for access to the directory and its files, because a user must have it in order to exercise any other permissions. In particular, a user must have this permission to access anything in the directory's subdirectories, even if the ACL on a subdirectory grants extensive permissions.
This permission enables a user to issue the following commands:
The ls command to list the names of the files and subdirectories in the directory
The ls -ld command to obtain complete status information for the directory element itself
The fs listacl command to examine the directory's ACL
This permission does not enable a user to read the contents of a file in the directory, to issue the ls -l command on a file in the directory, or to issue the fs listacl command with the filename as the -path argument. Those operations require the r (read) permission which is described in The Three File Permissions.
Similarly, this permission does not enable a user to issue the ls, ls -l, ls -ld, or fs listacl commands against a subdirectory of the directory. Those operations require the l permission on the ACL of the subdirectory itself.
This permission enables a user to add new files to the directory, either by creating or copying, and to create new subdirectories. It does not extend into any subdirectories, which are protected by their own ACLs.
This permission enables a user to remove files and subdirectories from the directory or move them into other directories (assuming that the user has the i permission on the ACL of the other directories).
This permission enables a user to change the directory's ACL. Members of the system:administrators group implicitly have this permission on every directory (that is, even if that group does not appear on the ACL). Similarly, the owner of a volume root directory implicitly has this permission on its ACL and those of all directories within the volume.
The three permissions in this group are meaningful with respect to files in a directory, rather than the directory itself or its subdirectories.
This permission enables a user to read the contents of files in the directory and to issue the ls -l command to stat the file elements.
This permission enables a user to modify the contents of files in the directory and to issue the chmod command to change their UNIX mode bits.
This permission enables the user to run programs that issue system calls to lock files in the directory.
AFS provides eight additional permissions that do not have a defined meaning, denoted by the uppercase letters A, B, C, D, E, F, G, and H.
You can write application programs that assign a meaning to one or more of the permissions, and then place them on ACLs to control file access by those programs. For example, you can modify a print program to recognize and interpret the permissions, and then place them on directories that house files that the program accesses. Use the fs listacl and fs setacl commands to display and set the auxiliary permissions on ACLs just like the standard seven.
You can combine the seven permissions in any way in an ACL entry, but certain combinations are more useful than others. Four of the more common combinations have corresponding shorthand forms. When using the fs setacl command to define ACL entries, you can provide either one or more of the individual letters that represent the permissions, or one of the following shorthand forms:
ACLs enable you both to grant and to deny access to a directory and the files in it. To grant access, use the fs setacl command to create an ACL entry that associates a set of permissions with a user or group, as described in Setting ACL Entries. When you use the fs listacl command to display an ACL (as described in Displaying ACLs), such entries appear underneath the following header, which uses the term rights to refer to permissions:
Normal rights
There are two ways to deny access:
The recommended method is simply to omit an entry for the user or group from the ACL, or to omit the appropriate permissions from the entry. Use the fs setacl command to remove or edit an existing entry, using the instructions in To add, remove, or edit normal ACL permissions. In most circumstances, this method is enough to prevent access of certain kinds or by certain users. You must take care, however, not to grant the undesired permissions to any groups to which such users belong.
The more explicit method for denying access is to use the -negative flag to the fs setacl command to create an entry that associates negative permissions with the user or group; for instructions, see To add, remove, or edit negative ACL permissions. The output from the fs listacl command lists negative entries underneath the following header:
Negative rights
When determining what type of access to grant to a user, the File Server first compiles a set of permissions by
examining all of the entries in the Normal rights section of the ACL. It then subtracts
any permissions associated with the user (or with groups to which the user belongs) on the Negative
rights section of the ACL. Therefore, negative permissions always cancel out normal permissions.
Using negative permissions reverses the usual semantics of the fs setacl command,
introducing the potential for confusion. In particular, combining the none shorthand
and the -negative flag constitutes a double negative: by removing an entry from the
Negative rights section of the ACL, you enable a user once again to obtain permissions
via entries in the Normal rights section. Combining the all shorthand with the -negative flag explicitly denies all
permissions.
Note also that it is pointless to create an entry in the Negative rights section
if an entry in the Normal rights section grants the denied permissions to the system:anyuser group. In this case, users can obtain the permissions simply by using the
unlog command to discard their tokens. When they do so, the File Server recognizes them
as the anonymous user, who belongs to the system:anyuser group but does not match the entries on the Negative
rights section of the ACL.
As previously mentioned, placing a group entry on an ACL enables you to control access for many users at once. You can grant a new user access to many files and directories simply by adding the user to a group that appears on the relevant ACLs. You can also create groups of machines, in which case any user logged on to the machine obtains the access that is granted to the group. On directories where they have the a permission on the ACL, users can define their own groups and can create ACL entries for any groups, not just groups that they create or own themselves. For instructions on creating groups of users or machines, and a discussion of the most effective ways to use different types of groups, see Administering the Protection Database.
AFS also defines the following two system groups, which can be very useful on ACLs because they potentially represent a large group of people. For more information about these groups, see The System Groups.
Includes anyone who can access the cell's file tree, including users who have logged in as the local superuser root, have connected to a local machine from somewhere outside the cell, and AFS users who belong to a foreign cell. This group includes users who do not have tokens that are valid for the local AFS servers; the servers recognize them as the user anonymous.
Note that creating an ACL entry for this group is the only way to extend access to AFS users from foreign cells, unless you create local authentication accounts for them.
Includes all users who have a valid AFS token obtained from the local cell's authentication service.
It is particularly useful to grant the l (lookup) permission to the system:anyuser group on the ACL of most directories in the file system, especially at the upper levels. This permission enables users only to learn the names of files and subdirectories in a directory, but without it they cannot traverse their way through the directories in the path to a target file.
A slightly more restrictive alternative is to grant the l permission to the system:authuser group. If that is still not restrictive enough, you can grant the l to specific users or groups, which cannot exceed about 20 in number on a given ACL.
Another reason to grant certain permissions to the system:anyuser group is to enable the correct operation of processes that provide services such as printing and mail delivery. For example, in addition to the l permission, a print process possibly needs the r (read) permission in order to access the contents of files, and a mail delivery process possibly requires the i (insert) permission to deliver new pieces of mail.
The ACL on the root directory of every newly created volume grants all permissions to the system:administrators group. You can remove this entry if you wish, but members of the system:administrators group always implicitly have the a (administer), and by default also the l, permission on every directory's ACL. The a permission enables them to grant themselves other permissions explicitly when necessary. To learn about changing this default set of permissions, see Administering the system:administrators Group.
| |  | |
| Chapter 14. Managing Access Control Lists |  | Displaying ACLs |