This chapter explains how to protect AFS files and directories by defining permissions on an access control list.
AFS augments and refines the standard UNIX scheme for controlling access to files and directories. Instead of using mode bits to define access permissions for individual files, as UNIX does, AFS stores an access control list (ACL) with each directory. It defines which users and groups can access the directory and the files it contains, and in what manner. An ACL can store up to about 20 entries, each of which pairs a user or group and a set of permissions. AFS defines seven permissions rather than the three that UNIX uses.
Another refinement to the standard UNIX protection scheme is that users can define their own protection groups and then place the groups on ACLs as though they were individual users. A group can include both users and machines. Each user who belongs to a group inherits all of the permissions granted to the group on the ACL. Similarly, all users who are logged into a machine that belongs to a group inherits all of the permissions granted to the group. You can create groups to place on ACLs and also use groups that other users have created. To learn more about group creation, see Using Groups.
In addition, AFS defines two system groups called system:anyuser and system:authuser. By placing them on ACLs, you can grant access to large numbers of users at once. See Using the System Groups on ACLs.
Although AFS uses ACLs to protect files and directories, it also uses the UNIX mode bits to a limited extent. See How AFS Uses the UNIX Mode Bits.
As noted, AFS associates an ACL with each directory, and it applies to all of the files stored in the directory. Files do not have separate ACLs. Defining access at the directory level has several consequences:
As a general rule, it makes sense to grant fairly liberal access to your home directory. If you need to protect certain files more closely, place them in subdirectories that have more restrictive ACLs.
There are seven standard AFS ACL permissions. Functionally, they fall into two groups: one that applies to the directory itself and one that applies to the files.
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 enables a user to issue the following commands:
This permission does not enable a user to read the contents of a file in the directory or to issue the ls -l or fs listacl commands with a filename as the 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.
The three permissions in this group are meaningful with respect to files in a directory, rather than the directory itself or its subdirectories.
AFS provides eight additional permissions that do not have a defined meaning. They are denoted by the uppercase letters A, B, C, D, E, F, G, and H.
Your system administrator can choose to 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. 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 Changing an ACL. When you use the fs listacl command to display an ACL (as described in Displaying an ACL), 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:
Negative rights
When determining what type of access to grant to a user, AFS first examines all of the entries in the normal permissions section of the ACL. It then subtracts any permissions associated with the user (or with groups to which the user belongs) on the negative permissions section of the ACL. Therefore, negative permissions always cancel out normal permissions.
Negative permissions can be confusing, because they reverse the usual meaning of the fs setacl command. In particular, combining the none shorthand and the -negative flag is a double negative: by removing an entry from the negative permissions section of the ACL, you enable a user once again to obtain permissions via entries in the normal permissions section. Combining the all shorthand with the -negative flag explicitly denies all permissions.
It is useless to create an entry in the negative permissions section if an entry in the normal permissions 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, AFS recognizes them as the anonymous user, who belongs to the system:anyuser group but does not match the entries on the negative permissions section of the ACL.
If your machine is configured to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit, then you can use the AFS fs listacl and fs setacl commands to display and set the ACLs on DFS directories and files that you own. However, DFS uses a slightly different set of permissions and a different syntax for ACL entries. See the DFS documentation or ask your system administrator.
AFS defines two system groups that grant access to a large number of users at once when placed on an ACL. However, you cannot control the membership of these groups, so consider carefully what kind of permissions you wish to give them. (You do control the membership of the groups you own; see Using Groups.)
The third system group, system:administrators, includes a small group of administrators who have extensive permissions in the cell. You do not generally need to put this group on your ACLs, because its members always have the a (administer) permission on every ACL, even if the group does not appear on it.
A user must have the l permission on a directory to access its subdirectories in any way. Even if users have extensive permissions on a subdirectory, they cannot access it if the parent directory's ACL does not grant the l permission.
You can grant the l permission in one of three ways: grant it to a system group (system:anyuser or system:authuser), grant it to individual users, or grant it to one or more groups of users defined by you or other users (see Using Groups). Granting the l permission to the system:anyuser group is the easiest option and is generally secure because the permission only enables users to list the contents of the directory, not to read the files in it. If you want to enable only locally authenticated users to list a directory's contents, substitute the system:authuser group for the system:anyuser group. Your system administrator has possibly already created an entry on your home directory's ACL that grants the r and l permissions to the system:anyuser group.
It is sometimes necessary to grant more extensive permissions to the system:anyuser group so that processes that provide printing and mail delivery service can work correctly. For example, printing processes sometimes need the r permission in addition to the l permission. A mail delivery process possibly needs the i permission to place new messages in your mail directory. Your system administrator has probably already created the necessary ACL entries. If you notice an ACL entry for which the purpose is unclear, check with your system administrator before removing it.
The only way to grant access to users from foreign cells who do not have an account in your cell is to put the system:anyuser group on an ACL. Remember, however, that such an entry extends access to everyone who can reach your cell, not just the AFS users from foreign cells that you have in mind.
To display the ACL associated with a file or directory, issue the fs listacl command.
Note for AFS/DFS Migration Toolkit users: If the machine on which you issue the fs listacl command is configured to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit, you can use the command to display the ACL on DFS files and directories. To display a DFS directory's Initial Container or Initial Object ACL instead of the regular one, include the fs listacl command's -id or -if flag. For more information, ask your system administrator. The fs command interpreter ignores the -id and -if flags if you include them when displaying an AFS ACL.
% fs listacl [<dir/file path>+]
where
The output for each file or directory specified as dir/file path begins with the following header to identify it:
Access list for dir/file path is
The Normal rights header appears on the next line, followed by lines that each pair a user or group name and a set of permissions. The permissions appear as the single letters defined in The AFS ACL Permissions, and always in the order rlidwka. If there are any negative permissions, the Negative rights header appears next, followed by pairs of negative permissions.
If the following error message appears instead of an ACL, you do not have the permissions needed to display an ACL. To specify a directory name as the dir/file path argument, you must have the l (lookup) permission on the ACL. To specify a filename, you must also have the r (read) permission on its directory's ACL.
fs: You don't have the required access permissions on 'dir/file path'
The following example displays the ACL on user terry's home directory in the ABC Corporation cell:
% fs la /afs/abc.com/usr/terry Access list for /afs/abc.com/usr/terry is Normal rights: system:authuser rl pat rlw terry rlidwka Negative rights: terry:other-dept rl jones rl
where pat, terry, and jones are individual users, system:authuser is a system group, and terry:other-dept is a group that terry owns. The list of normal permissions grants all permissions to terry, the rlw permissions to pat, and the rl permissions to the members of the system:authuser group.
The list of negative permissions denies the rl permissions to jones and the members of the terry:other-dept group. These entries effectively prevent them from accessing terry's home directory in any way; they cancel out the rl permissions extended to the system:authuser group, which is the only entry on the normal permissions section of the ACL that possibly applies to them.
The following example illustrates how you can specify pathnames in different ways, and the appearance of the output for multiple directories. It displays the ACL for three directories: the current working directory (which is a subdirectory of user terry's home directory), the home directory for user pat, and another subdirectory of terry's home directory called plans.
% fs listacl . /afs/abc.com/usr/pat ../plans Access list for . is Normal rights: system:anyuser rl pat:dept rliw Access list for /afs/abc.com/usr/pat is Normal rights: system:anyuser rl pat rlidwka terry rliw Access list for ../plans is Normal rights: terry rlidwka pat rlidw
To add, remove, or edit ACL entries, use the fs setacl command. By default, the command manipulates entries on the normal permissions section of the ACL. To manipulate entries on the negative permissions section, include the -negative flag as instructed in To Add, Remove, or Edit Negative ACL Permissions.
You can change any ACL on which you already have the a permission. You always have the a permission on the ACL of every directory that you own, even if you accidentally remove that permission from the ACL. (The ls -ld command reports a directory's owner.) Your system administrator normally designates you as the owner of your home directory and its subdirectories, and you possibly own other directories also.
If an ACL entry already exists for the user or group you specify, then the new permissions completely replace the existing permissions rather than being added to them. In other words, when issuing the fs setacl command, you must include all permissions that you want to grant to a user or group.
Note for AFS/DFS Migration Toolkit users: If the machine on which you issue the fs setacl command is configured to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit, you can use the command to set the ACL on DFS files and directories. To set a DFS directory's Initial Container or Initial Object ACL instead of the regular one, include the fs setacl command's -id or -if flag. For more information, ask your system administrator. The fs command interpreter ignores the -id and -if flags if you include them when setting an AFS ACL.
Issue the fs setacl command to edit entries in the normal permissions section of the ACL. To remove an entry, specify the none shorthand as the permissions. If an ACL entry already exists for a user or group, the permissions you specify completely replace those in the existing entry.
% fs setacl -dir <directory>+ -acl <access list entries>+
where
fs: 'filename': Not a directory
If you specify only one directory (or file) name, you can omit the -dir and -acl switches. For more on omitting switches, see Appendix B, AFS Command Syntax and Online Help.
To define the permissions, provide either:
On a single command line, you can combine user and group entries. Also, you can both combine individual letters and use the shorthand notations, but not within a single pair.
Either of the following example commands grants user pat the r and l permissions on the ACL of the notes subdirectory of the current working directory. They illustrate how it is possible to omit the -dir and -acl switches when you name only one directory.
% fs sa notes pat rl % fs sa pat read
The following example edits the ACL for the current working directory. It removes the entry for the system:anyuser group, and adds two entries: one grants all permissions except a to the members of the terry:colleagues group and the other grants the r and l permissions to the system:authuser group.
% fs sa -dir . -acl system:anyuser none terry:colleagues write \ system:authuser rl
Issue the fs setacl command with the -negative flag to edit entries in the negative permissions section of the ACL. To remove an entry, specify the none shorthand as the permissions. If an ACL entry already exists for a user or group, the permissions you specify completely replace those in the existing entry.
% fs setacl -dir <directory>+ -acl <access list entries>+ -negative
where
User terry has granted all access permissions except a to the group terry:team on her plans subdirectory.
% cd /afs/abc.com/usr/terry % fs listacl plans Access control list for plans is Normal rights: system:anyuser rl terry:team rlidwk terry rlidwka
However, terry notices that one of the members of the group, user pat, has been making inappropriate changes to files. To prevent this without removing pat from the group or changing the permissions for the terry:team group, terry creates an entry on the negative permissions section of the ACL that denies the w and d permissions to pat:
% fs setacl plans pat wd -negative % fs listacl plans Access control list for plans is Normal rights: system:anyuser rl terry:team rlidwk terry: rlidwka Negative rights: pat wd
In the previous example, user terry put pat on the negative permissions section of ACL for the plans subdirectory. But the result has been inconvenient and pat has promised not to change files any more. To enable pat to exercise all permissions granted to the members of the terry:team group, terry removes the entry for pat from the negative permissions section of the ACL.
% fs setacl plans pat none -negative % fs listacl plans Access control list for plans is Normal rights: system:anyuser rl terry:team rlidwk terry rlidwka
It is sometimes simplest to clear an ACL completely before defining new permissions on it, for instance if the mix of normal and negative permissions makes it difficult to understand how their interaction affects access to the directory. To clear an ACL completely while you define new entries, include the -clear flag on the fs setacl command. When you include this flag, you can create entries on either the normal permissions or the negative permissions section of the ACL, but not on both at once.
Remember to create an entry for yourself. As the owner of the directory, you always have the a (administer) permission required to replace a deleted entry, but the effects the effects of a missing ACL entry can be confusing enough to make it difficult to realize that the problem is a missing entry. In particular, the lack of the l (lookup) permission prevents you from using any shorthand notation in pathnames (such as a period for the current working directory or two periods for the parent directory).
Issue the fs setacl command with the -clear flag to clear the ACL completely before setting either normal or negative permissions. Because you need to grant the owner of the directory all permissions, it is better in most cases to set normal permissions at this point.
% fs setacl -dir <directory>+ -acl <access list entries>+ -clear [-negative]
where
The following example clears the ACL on the current working directory and creates entries that grant all permissions to user terry and all permissions except a to user pat.
% fs setacl . terry all pat write -clear % fs listacl . Access control list for . is Normal rights: terry rlidwka pat rlidwk
The fs copyacl command copies a source directory's ACL to one or more destination directories. It does not affect the source ACL at all, but changes each destination ACL as follows:
To copy an ACL, you must have the l permission on the source ACL and the a permission on each destination ACL. If you identify the source directory by naming a file in it, you must also have the r permission on the source ACL. To display the permissions you have on the two directories, use the fs listacl command as described in Displaying an ACL.
Note for AFS/DFS Migration Toolkit users: If the machine on which you issue the fs copyacl command is configured for access to a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit, you can use the command to copy ACLs between DFS files and directories also. The command includes -id and -if flags for altering a DFS directory's Initial Container and Initial Object ACLs as well as its regular ACL; for details, ask your system administrator. You cannot copy ACLs between AFS and DFS directories, because they use different ACL formats. The fs command interpreter ignores the -id and -if flags if you include them when copying AFS ACLs.
Issue the fs copyacl command to copy a source ACL to the ACL on one or more destination directories.
% fs copyacl -fromdir <source directory> -todir <destination directory>+ \ [-clear]
where
In this example, user terry copies the ACL from her home directory (the current working directory) to its plans subdirectory. She begins by displaying both ACLs.
% fs listacl . plans Access list for . is Normal rights: terry rlidwka pat rlidwk jones rl Access list for plans is Normal rights: terry rlidwka pat rl smith rl % fs copyacl -from . -to plans % fs listacl . plans Access list for . is Normal rights: terry rlidwka pat rlidwk jones rl Access list for plans is Normal rights: terry rlidwka pat rlidwk jones rl smith rl
Although AFS protects data primarily with ACLs rather than mode bits, it does not ignore the mode bits entirely. An explanation of how mode bits work in the UNIX file system is outside the scope of this document, and the following discussion assumes you understand them; if necessary, see your UNIX documentation. Also, the following discussion does not cover the setuid, setgid or sticky bits. If you need to understand how those bits work on AFS files, see the IBM AFS Administration Guide or ask your system administrator.
AFS uses the UNIX mode bits in the following way:
When you issue the UNIX chmod command on an AFS file or directory, AFS changes the bits appropriately. To change a file's mode bits, you must have the AFS w permission on the ACL of the file's directory. To change a directory's mode bits, you must have the d, i, and l permissions on its ACL.
Suppose terry is chairing a committee that is writing a proposal. As each section is approved, she turns off write access to that file to prevent further changes. For example, the following chmod command turns off the w mode bits on the file proposal.chap2. This makes it impossible for anyone to change the file, no matter what permissions are granted on the directory ACL.
% chmod -w proposal.chap2 % ls -l -rw-r--r-- 1 terry 573 Nov 10 09:57 conclusion -r--r--r-- 1 terry 573 Nov 15 10:34 intro -r--r--r-- 1 terry 573 Dec 1 15:07 proposal.chap2 -rw-r--r-- 1 terry 573 Nov 10 09:57 proposal.chap3 -rw-r--r-- 1 terry 573 Nov 10 09:57 proposal.chap4