This chapter explains how to protect AFS files and directories by defining permissions on an access control list. protection for files and directories access to AFS filespace granting and denying to users directories setting access control list ACL described access control list ACL 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: 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 its permissions 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, it inherits the current ACL of its parent directory. You can then set the subdirectory's ACL to be different from its parent's. However, do not make the ACL on the parent directory more restrictive than on a subdirectory, because that can prevent users from accessing the subdirectory even when they have the necessary permissions on its ACL. Specifically, a user must have the l (lookup) permission (defined in The AFS ACL Permissions) on the parent directory to reach its subdirectories. subdirectories, accessing access to AFS filespace controlling at directory level 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. access permissions on ACL permissions on ACL ACL permissions on ACL defined ACL permissions defined 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. 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. lookup 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 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 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 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 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. administer 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 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 w ACL permission The k (lock) permission This permission enables a user to run programs that issue system calls to lock files in the directory. k ACL permission lock ACL permission auxiliary ACL permissions ACL auxiliary permissions 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. ACL shorthand notation for grouping sets of permissions shorthand notation for ACL permissions permissions on ACL shorthand for 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 Represents all seven standard permissions (rlidwka) all shorthand for ACL permissions none Removes the entry from the ACL, leaving the user or group with no permission none shorthand for ACL permissions read Represents the r (read) and l (lookup) permissions read shorthand for ACL permissions write Represents all permissions except a (administer): rlidwk write shorthand for ACL permissions ACL normal vs. negative permissions ACL normal permissions ACL negative permissions permissions on ACL normal vs. negative normal ACL permissions defined normal ACL permissions setting 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 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 ACL permissions setting The recommended method is simply to omit an entry for the user or group from the ACL, or to omit the appropriate permissions from an entry. Use the fs setacl command to remove or edit an existing entry. In most cases, 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 place an entry on the negative permissions section of an ACL, by including the -negative flag to the fs setacl command. For instructions, see To Add, Remove, or Edit Negative ACL Permissions. The fs listacl command displays the negative permissions section of an ACL underneath the following header: 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. If a user or group is granted the l (lookup) and i (insert) permissions, but not the r (read) and/or w (write) permissions, this is commonly referred to as a "dropbox" for that user or group. What this means is that that user or group may deposit files in the directory, but they may not read or modify their file later, nor any other file in the directory. Know, however, that some of these restrictions are enforced on the client and not on the fileserver, and so should not be relied on for security. In particular, the fileserver does not know when a file is opened or closed on the client, and and so read and write permissions are granted to any user with "dropbox" permissions that owns the accessed file. Additionally, granting "dropbox" permissons to system:anyuser raises additional problems, if you want the dropbox to work for unauthenticated users. Any file deposited by an unauthenticated user will be owned by the unauthenticated user ID, and so would be readable and modifiable by anyone. In order to try and prevent accidentally revealing private information, the fileserver does not grant the implicit read permission to unauthenticated users, even if they have dropbox permissions. This may cause depositing files as an unauthenticated user to arbitrarily fail, and so you should not depend on granting dropbox permissions to unauthenticated users to work reliably. system groups using on ACLs system:anyuser group using on ACLs system:authuser group system:administrators group 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.) system:anyuser Includes anyone who can access the cell's file tree, including users who have tokens in the local cell, users who have logged in on a local AFS client machine but have not obtained tokens (such as the local superuser root), and users who have connected to a local machine from outside the cell. Creating an ACL entry for this group is the only way to extend access to AFS users from foreign cells, unless your system administrator creates 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 AFS authentication service. 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. subdirectories, accessing access to AFS filespace controlling for subdirectories 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. access to AFS filespace enabling for service processes 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. access to AFS filespace enabling for users from foreign cells 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. ACL displaying displaying ACL entries permissions on ACL displaying 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. Issue the fs listacl command. fs commands listacl commands fs listacl % 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 a file, the output displays the ACL on 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 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' examples displaying ACL for single directory The following example displays the ACL on user terry's home directory in the Example Corporation cell: % fs la /afs/example.com/usr/terry Access list for /afs/example.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. examples displaying ACLs for multiple directories 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/example.com/usr/pat ../plans Access list for . is Normal rights: system:anyuser rl pat:dept rliw Access list for /afs/example.com/usr/pat is Normal rights: system:anyuser rl pat rlidwka terry rliw Access list for ../plans is Normal rights: terry rlidwka pat rlidw changing ACLs setting permissions on ACL ACL setting permissions on ACL setting 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. creating ACL entry in normal permissions section ACL creating normal entry adding ACL entry to normal permissions section granting access to AFS filespace access to AFS filespace ACL entries control directories granting access files granting access 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. commands fs setacl fs commands setacl % 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. 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. For more on omitting switches, see Appendix B, OpenAFS Command Syntax and Online Help. -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) 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. examples adding a user to an ACL 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 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 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 creating ACL entry in negative permissions section ACL creating negative entry adding ACL entry to negative permissions section denying access with negative ACL entry directories denying access files denying access 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 commands setacl with -negative flag commands fs setacl % 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. 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. examples creating entry on negative permissions section of ACL User terry has granted all access permissions except a to the group terry:team on her plans subdirectory. % cd /afs/example.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 ACL replacing all entries ACL clearing replacing all entries on ACL erasing all ACL entries clearing all ACL entries removing all ACL entries directories replacing ACL 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 commands setacl completely replacing ACL % 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 ACL entries defined by the -acl argument. 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. examples replacing an ACL 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 ACL copying between directories creating ACL as copy of another copying ACL between directories directories copying ACLs between 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, which overwrites the destination ACL completely. If an entry is on both ACLs, the command changes the destination ACL entry to match the source ACL entry. 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. commands fs copyacl fs commands copyacl 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 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. -clear Completely overwrites each destination directory's ACL with the source ACL. examples copying ACL between directories 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 UNIX, differences with AFS mode bits, interpretation mode bits (UNIX) interpretation in AFS 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 OpenAFS Administration Guide or ask your system administrator. AFS uses the UNIX mode bits in the following way: It uses the initial bit to distinguish files and directories. 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. The AFS ACL alone controls directory access. For a file, the owner (first) set of bits interacts with the ACL entries that apply to the file in the following way. AFS does not use the group or world (second and third sets) of mode bits at all. 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 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. 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. commands chmod chmod command examples using chmod 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