To control access to a directory and all of the files in it, AFS associates an access control list (ACL) with it, rather than the mode bits that the UNIX file system (UFS) associates with individual files or directories. AFS ACLs provide more refined access control because there are seven access permissions rather than UFS's three, and there is room for approximately 20 user or group entries on an ACL, rather than just the three UFS entries (owner, group, and other). This chapter explains how to perform the following tasks by using the indicated commands: Examine access control list fs listacl Edit ACL's normal permissions section fs setacl Edit ACL's negative permissions section fs setacl with -negative flag Replace an ACL fs setacl with -clear flag Copy an ACL fs copyacl Remove obsolete AFS UIDs fs cleanacl protection of file data see also: ACL protection of file data AFS compared to UFSACL 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. UFS file protection compared to AFS protection of file data AFS compared to UFSACL ACL compared to UNIX protection 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: directory-level data protection implications 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. access permissions on ACL (see entries: permissions on ACL, ACL) permissions on ACL defined ACL permissions defined 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. The l (lookup) permission 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. lookup ACL permission l ACL permission l ACL permission 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. The i (insert) permission 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. insert ACL permission i ACL permission i ACL permission The d (delete) permission 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). delete ACL permission d ACL permission d ACL permission The a (administer) permission 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 directory implicitly has this permission on its ACL and those of all directories below it that he or she owns. administer ACL permission a ACL permission a ACL permission The three permissions in this group are meaningful with respect to files in a directory, rather than the directory itself or its subdirectories. The r (read) permission 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. read ACL permission r ACL permission) r ACL permission The w (write) permission 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. write ACL permission write ACL permission w ACL permission The k (lock) permission This permission enables the user to run programs that issue system calls to lock files in the directory. lock ACL permission k ACL permission k ACL permission undefined ACL permissions auxiliary ACL permissions ACL auxiliary permissions 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. ACL shorthand notation for grouping permissions shorthand notation ACL permissions 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: all shorthand for ACL permissions all Represents all seven standard permissions (rlidwka). none shorthand for ACL permissions none Removes the entry from the ACL, leaving the user or group with no permissions. read shorthand for ACL permissions read Represents the r (read) and l (lookup) permissions. write shorthand for ACL permissions write Represents all permissions except a (administer): rlidwk. ACL normal vs. negative permissions normal ACL permissions defined negative ACL permissions defined 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. group ACL entry, usefulness of ACL group entries, usefulness 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. system groups using on ACLs group system-defined on ACLs ACL system groups on system:anyuser group using on ACLs system:authuser group using on ACLs 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. system:anyuser 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. ACL foreign users on system:authuser 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. ACL displaying displaying ACL entries To display the ACL associated with a file, directory or symbolic link, issue the fs listacl command. The output for a symbolic link displays the ACL that applies to its target file or directory, rather than the ACL on the directory that houses the symbolic link. 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 and Initial Object ACL instead of the regular one, include the fs listacl command's -id or -if flag. For instructions, see the OpenAFS/DFS Migration Toolkit Administration Guide and Reference. The fs command interpreter ignores the -id and -if flags if you include them when displaying an AFS ACL. fs commands listacl commands fs listacl Issue the fs listacl command. % fs listacl [<dir/file path>+] where la Is an acceptable alias for listacl (and lista is the shortest acceptable abbreviation). dir/file path Names one or more files or directories for which to display the ACL. For files, the output displays the ACL for its directory. If you omit this argument, the output is for the current working directory. Partial pathnames are interpreted relative to the current working directory. You can also use the following notation on its own or as part of a pathname: . (A single period). Specifies the current working directory. .. (Two periods). Specifies the current working directory's parent directory. * (The asterisk). Specifies each file and subdirectory in the current working directory. The ACL displayed for a file is always the same as for its directory, but the ACL for each subdirectory can differ. The following error message indicates that 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' Members of the system:administrators group and the directory's owner (as reported by the ls -ld command) implicitly have the a (administer) permission on every directory's ACL, and can use the fs setacl command to grant themselves the required permissions; for instructions, see Setting ACL Entries. 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. 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 permissions: system:authuser rl pat rlw terry rlidwka Negative permissions: 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 r (read), l (lookup), and w (write) permissions to pat, and the r and l permissions to the members of the system:authuser group. The list of negative permissions denies the r and l 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, because they cancel out the r and l permissions extended to the system:authuser group, which is the only entry on the Normal rights section of the ACL that possibly applies to them. ACL setting entries ACL editing entries ACL adding entries ACL removing entries changing ACL entries setting ACL entries granting file access by setting ACL creating ACL entry adding ACL entry normal permissions removing ACL entry 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. You must have the a (administer) permission on an ACL to edit it. The owner of a directory (as reported by the ls -ld) command and members of the system:administrators group always implicitly have it on every ACL. By default, members of the system:administrators group also implicitly have the l (lookup) permission. 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 and Initial Object ACL instead of the regular one, include the fs setacl command's -id or -if flag. For instructions, see the OpenAFS/DFS Migration Toolkit Administration Guide and Reference. The fs command interpreter ignores the -id and -if flags if you include them when setting an AFS ACL. fs commands setacl commands fs setacl Verify that you have the a (administer) permission on each directory for which you are editing the ACL. If necessary, issue the fs listacl command, which is fully described in Displaying ACLs. % fs listacl [<dir/file path>] 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, the permissions you specify completely replace those in the existing entry. % fs setacl -dir <directory>+ -acl <access list entries>+ where sa Is an acceptable alias for setacl (and seta is the shortest acceptable abbreviation). -dir Names one or more directories to which to apply the ACL entries defined by the -acl argument. Partial pathnames are interpreted relative to the current working directory. Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a read-only volume. By convention, you indicate the read/write path by placing a period before the cell name at the pathname's second level (for example, /afs/.abc.com). For further discussion of the concept of read/write and read-only paths through the filespace, see The Rules of Mount Point Traversal. You can also use the following notation on its own or as part of a pathname: . (A single period). If used by itself, sets the ACL on the current working directory. .. (Two periods). If used by itself, sets the ACL on the current working directory's parent directory. * (The asterisk). Sets the ACL on each of the subdirectories in the current working directory. You must precede it with the -dir switch, since it potentially designates multiple directories. The fs command interpreter generates the following error message for each file in the directory: fs: 'filename': Not a directory If you specify only one directory or file name, you can omit the -dir and -acl switches. -acl Specifies one or more ACL entries, each of which pairs a user or group name and a set of permissions. Separate the pairs, and the two parts of each pair, with one or more spaces. To define the permissions, provide either: One or more of the letters that represent the standard or auxiliary permissions (rlidwka and ABCDEFGH), in any order One of the four shorthand notations: all (equals rlidwka) none (removes the entry) read (equals rl) write (equals rlidwk) For a more detailed description of the permissions and shorthand notations, see The AFS ACL Permissions. On a single command line, you can combine user and group entries. You can also use individual letters in some pairs and the shorthand notations in other pairs, but cannot combine letters and shorthand notation within a single pair. Either of the following examples grants user pat the r (read) and l (lookup) permissions on the ACL of the notes subdirectory in the issuer's home 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 ~/notes 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 (administer) to the members of the terry:colleagues group and the other grants the r (read) and l (lookup) permissions to the system:authuser group. The command appears on two lines here only for legibility. % fs sa -dir . -acl system:anyuser none terry:colleagues write \ system:authuser rl fs commands setacl with -negative flag commands fs setacl with -negative flag creating ACL entry in negative permissions section adding ACL entry negative permissions denying file access with negative ACL entry Verify that you have the a (administer) permission on each directory for which you are editing the ACL. If necessary, issue the fs listacl command, which is fully described in Displaying ACLs. % fs listacl [<dir/file path>] 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 sa Is an acceptable alias for setacl (and seta is the shortest acceptable abbreviation). -dir Names one or more directories to which to apply the negative ACL entries defined by the -acl argument. Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a read-only volume. For a detailed description of acceptable values, see To add, remove, or edit normal ACL permissions. -acl Specifies one or more ACL entries, each of which pairs a user or group name and a set of permissions. Separate the pairs, and the two parts of each pair, with one or more spaces. For a detailed description of acceptable values, see To add, remove, or edit normal ACL permissions. Keep in mind that the usual meaning of each permission is reversed. -negative Places the entries defined by the -acl argument on the negative permissions section of the ACL for each directory named by the -dir argument. The following example denies user pat the w (write) and d (delete) permissions for the project subdirectory of the current working directory. % fs sa project pat wd -neg ACL replacing all entries ACL clearing replacing all entries on ACL erasing all ACL entries clearing all ACL entries removing all ACL entries 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 a user's 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 that grants appropriate permissions to the directory's owner. The owner implicitly has the a (administer) permission required to replace a deleted entry, but the effects of a missing ACL entry (particularly the lack of the lookup permission) can be so confusing that it becomes difficult for the owner to realize that the missing entry is causing the problems. fs commands setacl with -clear flag commands fs setacl with -clear flag Verify that you have the a (administer) permission on each directory for which you are editing the ACL. If necessary, issue the fs listacl command, which is fully described in Displaying ACLs. % fs listacl [<dir/file path>] 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 sa Is an acceptable alias for setacl (and seta is the shortest acceptable abbreviation). -dir Names one or more directories to which to apply the negative ACL entries defined by the -acl argument. Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a read-only volume. For a detailed description of acceptable values, see To add, remove, or edit normal ACL permissions. -acl Specifies one or more ACL entries, each of which pairs a user or group name and a set of permissions. Separate the pairs, and the two parts of each pair, with one or more spaces. Remember to grant all permissions to the owner of the directory. For a detailed description of acceptable values, see To add, remove, or edit normal ACL permissions. -clear Removes all entries from each ACL before creating the entries indicated by the -acl argument. -negative Places the entries defined by the -acl argument on the negative permissions section of each ACL. ACL copying between directories creating ACL as copy of another copying ACL between directories 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: If an entry on the source ACL does not exist on the destination ACL, the command copies it to the destination ACL. If an entry on the destination ACL does not also exist on the source ACL, the command does not remove it unless you include the -clear flag to overwrite the destination ACL completely. If an entry is on both ACLs, the command changes the permissions on the destination ACL entry to match the source ACL entry. Note for AFS/DFS Migration Toolkit users: If the machine is configured to enable AFS users to access a DCE cell's DFS filespace via the AFS/DFS Migration Toolkit, then you can use the fs copyacl 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; see the OpenAFS/DFS Migration Toolkit Administration Guide and Reference. 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. fs commands copyacl commands fs copyacl Verify that you have the l (lookup) permission on the source ACL and the a (administer) permission on each destination ACL. To identify the source directory by naming a file in it, you must also have the r (read) permission on the source ACL. If necessary, issue the fs listacl command, which is fully described in Displaying ACLs. % fs listacl [<dir/file path>] Issue the fs copyacl command to copy a source ACL to the ACL on one or more destination directories. (The command appears here on two lines only for legibility.) % fs copyacl -fromdir <source directory> -todir <destination directory>+ \ [-clear] where co Is the shortest acceptable abbreviation for copyacl. -fromdir Names the source directory from which to copy the ACL. Partial pathnames are interpreted relative to the current working directory. If this argument names a file, the ACL is copied from its directory. -todir Names each destination directory to which to copy the source ACL. Partial pathnames are interpreted relative to the current working directory. Filenames are not acceptable. Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a read-only volume. By convention, you indicate the read/write path by placing a period before the cell name at the pathname's second level (for example, /afs/.abc.com). For further discussion of the concept of read/write and read-only paths through the filespace, see The Rules of Mount Point Traversal. -clear Completely overwrites each destination directory's ACL with the source ACL. The following example copies the ACL from the current working directory's notes subdirectory to the plans subdirectory. The issuer does not include the -clear flag, so the entry for user pat remains on the plans directory's ACL although there is no corresponding entry on the notes directory's ACL. % fs la notes plans Access list for notes is Normal permissions: terry rlidwka smith rl jones rl Access list for plans is Normal permissions: terry rlidwk pat rlidwk % fs copyacl notes plans % fs la notes plans Access list for notes is Normal permissions: terry rlidwka smith rl jones rl Access list for plans is Normal permissions: terry rlidwka pat rlidwk smith rl jones rl ACL removing obsolete AFS IDs removing obsolete AFS IDs from ACL AFS UID removing obsolete from ACL AFS GID removing obsolete from ACL ACL cleaning When you remove a user or group entry from the Protection Database, the fs listacl command displays the user's AFS UID (or group's AFS GID) in ACL entries, rather than the name. In the following example, user terry has an ACL entry for the group terry:friends (AFS GID -567) on her home directory in the ABC Corporation cell, and then removes the group from the Protection Database. % fs listacl /afs/abc.com/usr/terry Access list for /afs/abc.com/usr/terry is Normal permissions: terry:friends rlik system:anyuser l terry rlidwka % pts delete terry:friends % fs listacl /afs/abc.com/usr/terry Access list for /afs/abc.com/usr/terry is Normal permissions: -567 rlik system:anyuser l terry rlidwka Leaving AFS IDs on ACLs serves no function, because the ID no longer corresponds to an active user or group. Furthermore, if the ID is ever assigned to a new user or group, then the new possessor of the ID gains access that the owner of the directory actually intended for the previous possessor. (Reusing AFS IDs is not recommended precisely for this reason.) To remove obsolete AFS UIDs from ACLs, use the fs cleanacl command. commands fs cleanacl fs commands cleanacl Verify that you have the a (administer) permission on each directory for which you are cleaning the ACL. If necessary, issue the fs listacl command, which is fully described in Displaying ACLs. % fs listacl [<dir/file path>] Issue the fs cleanacl command to remove entries for obsolete AFS IDs. % fs cleanacl [<dir/file path>+] where cl Is the shortest acceptable abbreviation of cleanacl. dir/file path Names each directory for which to clean the ACL. If this argument names a file, its directory's ACL is cleaned. Omit this argument to clean the current working directory's ACL. Specify the read/write path to each directory, to avoid the failure that results when you attempt to change a read-only volume. By convention, you indicate the read/write path by placing a period before the cell name at the pathname's second level (for example, /afs/.abc.com). For further discussion of the concept of read/write and read-only paths through the filespace, see The Rules of Mount Point Traversal. You can also use the following notation on its own or as part of a pathname: . (A single period). If used by itself, cleans the current working directory's ACL. .. (Two periods). If used by itself, cleans the ACL on the current working directory's parent directory. * (The asterisk). Cleans the ACL of each of the subdirectories in the current working directory. However, if you use the asterisk and there are obsolete AFS IDs on any directory's ACL, the following error message appears for every file in the directory: fs: 'filename': Not a directory If there are obsolete AFS IDs on a directory, the command interpreter displays its cleaned ACL under the following header. Access list for directory is now If a directory's ACL has no obsolete AFS IDs on it, the following message appears for each. Access list for directory is fine. UNIX mode bits, interpretation in AFS UFS mode bits, interpretation in AFS mode bits (UNIX) interpretation in AFS Although AFS uses ACLs to protect file data rather than the mode bits that UFS uses, it does not ignore the mode bits entirely. When you issue the 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 (write) permission on the ACL of the file's directory. To change a directory's mode bits, you must have the d (delete), i (insert), and l (lookup) permissions on its ACL. AFS also uses the UNIX mode bits as follows: It uses the initial bit to determine the element's type. This is the bit that appears first in the output from the ls -l command and shows the hyphen (-) for a file or the letter d for a directory. It does not use any of the mode bits on a directory. For a file, the first (owner) set of bits interacts with the ACL entries that apply to the file in the following way: If the first r mode bit is not set, no one (including the owner) can read the file, no matter what permissions they have on the ACL. If the bit is set, users also need the r (read) and l permissions on the ACL of the file's directory to read the file. If the first w mode bit is not set, no one (including the owner) can modify the file. If the w bit is set, users also need the w and l permissions on the ACL of the file's directory to modify the file. There is no ACL permission directly corresponding to the x mode bit, but to execute a file stored in AFS, the user must also have the r and l permissions on the ACL of the file's directory.