+A  Click here to enlarge/reduce to/back from full screen 
Paul Scherrer Institut PSI AIT LINUX Support

PSI Home |  LOG Home |  AIT Home |  Search |  Helpdesk |  Contact Us | 





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

4.1. 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/psi.ch/sys
Access list for /afs/psi.ch/sys/ is
Normal rights:
  swinst rlidwk
  system:administrators rlidwka
  system:anyuser rl
  linuxsepp rlidwka

Most 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 swinst protection group (see section Protection groups), can also write files in the directory, and add/delete files in the directory. Additionally, members or the group linuxsepp may change the ACLs for the directory.

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

4.2.1. Directory access rights

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

lookup: 'l'

The lookup right allows the possessor:

  • 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 subdirectories ACL.

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

insert: 'i'

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

delete: 'd'

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

administer: 'a'

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

4.2.2. File access rights

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

read: 'r'

The read right allows the possessor to look at the contents of the directory. For files in the directory, the possessor can read the actual data in the file.

write: 'w'

The write right allows the possessor to modify the contents of files in the directory and to modify their UNIX mode bits

lock: 'k'

The lock right allows the possessor to run programs that need to 'flock' files in the directory.

4.3. 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/psi.ch/user/j/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.

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/psi.ch/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.

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

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

Prev   
3. Authentication Home