AFS ACLs

One significant difference in the way that AFS works compared to Unix/NFS is in the use of file permissions. AFS uses Access Control Lists (ACLs), and these apply to directories. All files within a directory share the same access control permissions. Be aware that moving a file from one location to another may change its access permissions - it will inherit the permissions of the directory into which it is moved. New directories inherit the ACLs of their parent directory. Generally, the traditional Unix file permissions are ignored for files stored in AFS and have no effect on who can access that file.

Each directory in AFS has an associated ACL, in the same way that every directory in a traditional filesystem has ordinary Unix permissions - the ACLs, though, have greater flexibility and finer granularity.

Each ACL can consist of up to 20 group-permissions pairs. The group can be several users (including user-definable groups), or a single user, or one or more machines. The permissions can affect the directory itself, or operations on all files in that directory, and they can be negative (withdrawing permissions) as well as positive (granting permissions).

Directory permissions are:

• l (lookup):
  Permission to search or list directories, and access sub-directories
  
• i (insert):
  Permission to create files and immediate sub-directories
  
• d (delete):
  Permission to remove files and subdirectories
  
• a (administer):
  Permission to change the ACL
  

File permissions are:

• r (read):
  Permission to read the contents of files in the directory, and to get file details (long listing)
  
• w (write):
  Permission to modify the contents of files in the directory and to use the 'chmod' command.
  
• k (lock):
  Permission to run programs that issue system calls to lock files in the directory.
  

There are shortcuts for some sets of permissions:

• all:
  Fairly obvious - this represents all permissions (rlidwka).
  
• none:
  Again, fairly obvious - using this removes all permissions.
  
• read:
  Stands for only r (read) and l (lookup) permissions.
  
• write:
  Stands for all permissions except a (administer), namely rlidwk.
  

An ACL might look something like:

    % fs listacl /afs/inf.ed.ac.uk/user/f/fred
    Access list for /afs/inf.ed.ac.uk/user/f/fred is
    Normal rights:
      system:administrators rlidwka
      system:authuser rl
      fred rlidwka
    % 
    

- where user 'fred' has all permissions listed above, as do members of the "root" or "superuser" group 'system:administrators'. Any authorised user (any users with valid AFS Tokens) are automatically members of the group 'system:authuser') and can list files and directories, but nothing more.

In general, the permissions (ACLs) on your home directory should be fairly open. If you want to protect certain files, these should be placed in sub-directories with more restrictive ACLs.

For more information on ACLs, see the "Protecting your Directories and Files" chapter in the OpenAFS User Guide.

Note that the fs command only operates on directories it is given as arguments. It will not make any changes to sub-directories of these directories. There is a wrapper script fsr available on DICE machines however which will carry out fs operations recursively on sub-directories.

Examples

The following examples should illustrate the use and application of ACLs. Note that ACL commands are usually additive, and thus depend on existing ACLs. The following examples use a (non-existent) user, "fred", and the default permissions on "/home/fred" are assumed to be:

    % cd
    % fs listacl .
    Access list for fred is
    Normal rights:
    system:administrators rlidwka
    fred rlidwka
    %

• To allow everyone to see (read, lookup) files in your home directory (assuming your home directory is your current directory):

      % fs setacl . system:anyuser read
  

• To remove all permissions for everybody except the owner on sub-directory "private":

      % fs setacl private system:anyuser none
  

• To give all authenticated users read permissions on the directory 'public' and all sub-directories of that directory

      % fsr setacl public system:authuser read
  

Unix File Permissions

As mentioned above, Unix group and world permissions are ignored. However, the user permissions do have relevance - if these (the "rw" bits - the "x" is ignored) are not set, then no access is possible, despite any ACL settings to the contrary. Conversely, if your files have "-rw-rw-rw-" Unix permissions, but only user access under AFS (and we are talking only about files under the control of AFS here), then only the user can access those files (despite the Unix group and world permission settings).

Note also that only members of the "system:administrators" AFS group can use the 'chmod' command to turn on the setuid, setgid or sticky mode bits on files under the control of AFS.

AFS-awareness

Not many Unix utilities take AFS into account when manipulating or managing files and directories. For example, when copying files recursively ('cp -R') or in batches ('tar', 'cpio'), the ACLs will be ignored. There is, however, an AFS-aware utility ('up <from> <to'>) that will perform a recursive copy and preserve ACLs (the name "up" refers to the collecting or batching up of files, rather than moving them up in the filesystem hierarchy - you can use 'up' to move files "down" too).