Go to the previous, next section.
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.
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.
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.
The four rights in this group apply to the directory itself. They are:
The three rights in this group only apply to files in the directory. They are:
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
a
) (i.e.,
rlidwk
)
read
rl
)
all
rlidwka
)
none
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.
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'.
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
system:authuser
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.