The AFS ACL Permissions

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 Directory Permissions

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.

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.

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).

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 volume root directory implicitly has this permission on its ACL and those of all directories within the volume.

The Three File Permissions

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.

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.

The k (lock) permission

This permission enables a user to run programs that issue system calls to lock files in the directory.

The Eight 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.

Shorthand Notation for Sets of 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

Represents all seven standard permissions (rlidwka)

none

Removes the entry from the ACL, leaving the user or group with no permission

read

Represents the r (read) and l (lookup) permissions

write

Represents all permissions except a (administer): rlidwk

About Normal and Negative Permissions

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:

  1. 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.

  2. 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.

Setting DFS ACLs

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.

Dropbox Permissions

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.