Configure AFS Access Rights

Data access in AFS is controlled by per directory access control lists (ACLs), which map user or group identities to a set of access rights. The listacl and setacl subcommands of the fs command suite are the interface to list and change the ACLs of a directory. Here is an example of a listing:

$ fs listacl $HOME/alliance
Access list for /afs/cern.ch/user/p/pam/alliance is
Normal rights:
     pam rlidwka
     jim rlidwk

To understand what type of rights have been granted to users pam and jim, this shows the seven rights provided by AFS to control access to a directory and to the files that the directory contains:

  • r = “read” allows the named user to read the file content and to query file status.
  • l = “lookup” allows the user to list the files and directories, to examine the ACL and to access the subdirectories.
  • i = “insert” allows the user to add new files and directories.
  • d = “delete” allows the user to remove files from a directory and to remove subdirectories, for which they have insert right.
  • w = “write” allows the user to change the file content (and also to change the UNIX permission bits, see below).
  • k = “lock” allows the user to use full-file advisory locks. (Note that there is no byte-range locking available in AFS.)
  • a = “administer” allows the user to change the ACL of a directory.

An additional constraint to make use of these privileges is that the user has at least the right to list (access right “l”) all parent directories.

To make life easier when setting ACLs via fs setacl, AFS provides some shortcuts to assign certain sets of rights:

  • “read” corresponds to rl and provides read access;
  • “write” corresponds to rlidwk and grants read and write access;
  • “all” corresponds to rlidwka and gives full access;
  • “none” removes all permissions for a user.

Assigning permission “none” removes the rights of a user but does not prevent accessing all cases because the user may be a member of a group that still has the right to access a directory. To prevent access to directories explicitly, ACLs in AFS support negative rights. By adding the negative option when setting ACLs, you can deny users rights that they would otherwise have by virtue of their group membership.

$ fs setacl -dir $HOME/alliance -acl dwight all -negative
$ fs listacl $HOME/alliance
...
Negative rights:
     dwight rlidwka

User dwight has now been denied all rights on the alliance directory, even if a group where he is a member is granted access later on. Caveat: if anonymous groups like system:anyuser are on the ACLs, the assignment of negative rights will not have the desired effect.

A common pitfall

By far the most confusing parameter that comes with the fs setacl command is the -clear option. This does not clear all of the rights of a given user or group but rather acts as a two-step command that wipes out the whole ACL and then assigns the rights given.

Taking our example from above,

$ fs setacl -dir $HOME/alliance -acl dwight all -clear

would not remove all permissions for user dwight but remove all entries from the ACL and then assign all permissions to dwight, which is contrary to the original intention.

How do ACLs and UNIX permission bits interact?

For directories, AFS completely ignores all of the UNIX permission bits – only the AFS ACL rights concerning directories (i.e. lida) are taken into account.

For files, the situation is a little different: AFS also ignores the group and world permissions for files, but the user permission bits act as an additional level of access control after the ACL permission checking has taken place.

  • The r bit allows anyone with rl on his ACL to read the file. If the r bit is not set, no one can read that file (not even the owner).
  • The w bit allows anyone with wl on his ACL to write to the file. If the w bit is not set, no-one can write that file (not even the owner).
  • The x bit allows anyone with rl on his ACL to execute the file. If the x bit is not set, no one can execute that file (not even the owner). This also implies that you cannot have a file in AFS that a user can execute but not read.

So, by using the combination of ACLs and UNIX permission bits it is possible to define something close to a per file access control, even though it does not provide the full flexibility of AFS’ per directory ACLs. There is currently a discussion in the AFS community to extend AFS to support fully fledged per file ACLs.

It should be emphasized that AFS does not really care about group membership or user ID (although there have been applications in the past that tried to outsmart the system and take decisions based on that). As a consequence, you should not be worried if an ls -l displays unknown owners or groups, because really only the UNIX owner bits matter for AFS.

Further information

The openAFS website provides information about all AFS commands http://docs.openafs.org/Reference/index.html external link.