Access control lists

Access control lists (ACLs) are the main way that AFS uses to control access to files and directories. The most important point to bear in mind when discussing ACLs is that only directories have ACLs in AFS; access to files is controlled by the ACL of the containing directory.

Another important point to bear in mind is that when you create a new subdirectory, it automatically inherits the ACL that the parent had at the time it was created, i.e., changing the parent ACL in the future will not change the child.

ACLs override or replace almost all of the UNIX protection bits. See See section Unix bits in AFS for more details.

Examining the ACL for a directory: Examining the ACL for a directory
How to decode an ACL: How to decode an ACL
Changing the ACL of a directory: Changing the ACL of a directory
Unix bits in AFS: Unix bits in AFS
Protection groups: Protection groups

Examining the ACL for a directory

You may use the command `fs la', or `fs listacl', to examine the access control list that applies to a directory. For example:

% fs la /afs/nih/@sys/usr/local/gnu
Access list for /afs/nih/@sys/usr/local/gnu is
Normal rights:
  gnu rlidwk
  amjudge a
  system:administrators rlidwka
  system:anyuser rl

Every ACL contains `system:administrators rlidwka'; the entry may safely be ignored. The rest of this ACL says that anyone can read files in this directory, and list the contents of the directory. Members of the `gnu' protection group (see section Protection groups), can also write files in the directory, and add/delete files in the directory. Additionally, user `amjudge' may change the ACLs for the directory.

How to decode an ACL

Unlike UNIX, which has only three basic rights that may be controlled, AFS has seven different rights which may be individually controlled. These rights are subdivided into two groups: four directory access rights, and three file access rights.

Directory access rights: Directory access rights
File access rights: File access rights

Directory access rights

The four rights in this group apply to the directory itself. They are:

`l'

The lookup right allows the possessor:

to issue `ls' to list the names of the files and subdirectories in the directory. It does not allow the possessor to list the contents of subdirectories unless she also has the lookup right in the subdirectory's ACL.

to `ls -l' the directory itself, and examine the ACL for the directory.

to access the directory's subdirectories, subject to their own ACLs.

`i'

The insert right allows the possessor to add new files and subdirectories to the directory.

`d'

The delete right allows the possessor to remove files and subdirectories from the directory.

`a'

The administer right allows the possessor to change the ACL for the directory.

File access rights

The three rights in this group only apply to files in the directory. They are:

`r': The read right allows the possessor to look at the contents of the directory (i.e. `ls -l'). For files in the directory, the possessor can read the actual data in the file.
`w': The write right allows the possessor to modify the contents of files in the directory and to modify their UNIX mode bits with the `chmod' command.
`k': The lock right allows the possessor to run programs that need to `flock' files in the directory.

Changing the ACL of a directory

The ACL of a directory may be changed using the `fs setacl' command. By default, `fs sa' adds to or alters the existing ACL, rather than replacing it entirely. So, for example, if you wish to give user `joe' the right to insert and delete files in a directory, you can say:

fs sa /afs/nih/foo/bar joe di

As well as accepting any combination of the seven valid AFS rights as an argument, `fs sa' also accepts the following shorthand notations:

write: All rights except administer (a) (i.e., rlidwk)
read: Read and lookup rights (rl)
all: All seven rights (rlidwka)
none: no rights -- this removes the user's entry from the ACL entirely.

So, if you wish to remove `system:anyuser' from an ACL and allow `system:authuser' to read files, you could say:

fs sa /afs/nih/foo/bar system:anyuser none system:authuser read

It is also possible to set negative access rights on a directory, denying access, but this won't be discussed here.

Unix bits in AFS

The UNIX mode bits set on a directory have no effect in AFS and may be safely ignored.

However, the first three bits (the user bits) of a file's mode bits do have a meaning in AFS. The file bits may be used to further restrict access to a file that the ACL allows access to.

So, for example, if the AFS ACL allows write access to a directory, but the file bits look like `-r--??????', then the user will not be allowed to write to the file.

Remember, however, that the user bits are applied to anyone who has access to the file; the owner of the file is irrelevant. Also, anyone who has write access to the file through the ACL will be allowed to change the protection bits using `chmod'.

Protection groups

An AFS protection group is a somewhat similar concept to a UNIX user group, except that it is used exclusively for file protection in access control lists. Another difference is that AFS protection groups are managed by the distributed database component of AFS, and therefore is always up to date and may be modified from any AFS client in the cell.

AFS provides a number of predefined protection groups that may be used in any ACL:

system:anyuser: This is similar to world permissions in UNIX. Any AFS user (anywhere in the world) can access files or directories made accessible using this ACL.
system:authuser: This is a more restrictive version of `system:anyuser': only users who have authenticated within the local cell may access files made accessible using this ACL.

Users may create or manage their own protection groups, that can be used by any user in any ACL. See the AFS User's Guide for more details.

Go to the previous, next section.

Back up to ALW Home Page