PNCE User Intro to AFS ACLS

PNCE User Documentation

Introduction to AFS Access Control Lists

The PNCE-Unix/Glue Clusters use the Andrew File System (AFS) for many of the file systems you have access to (the major exceptions being the /tmp directory and scratch space, as well as any local disk storage provided on a personal workstation). Although AFS has many advantages from a security and flexibility standpoint, these differences may cause confusion to users used to the traditional Unix method of access control. This document is intended to help allay some of that confusion.

If you are trying to secure some files and are confused about the ACLs, please feel free to contact PCS to ensure the ACLs are set correctly. Once private information is made publicly accessible, it can be difficult to contain it again.

Traditional Unix Filesystem Access Control

Traditional Unix file systems (e.g. UFS) use a fairly simple access control mechanism. Every file (including directories) has an owner, and an owning group. They also have a set of access control bits which users are probably familiar with as a set of three rwx fields visible on the left when looking at the output of an ls -l command. E.g.,

-rwxr-x--- 1 joe users 8743 Mar 15 16:58
Here we have a script, named owned by user joe and the group users. The first - indicated this is a regular file, and the next nine characters indicate the access rights (from left to right):

The main advantages of this scheme is that it is simple. It is however, rather limited. If Joe wants Jane and John to be able to read and execute the file, but no one else, a group containing only Jane and John would need to be created by the superuser (assuming users contains more than just those three). This quickly becomes unfeasable as the number of users and the number of potential subsets of users that one may wish to restrict to increases. And even then, what if additionally Sara and Stephen should be given read, write, and execute rights. The traditional scheme just does not offer that sort of flexibility.

AFS Access Control

AFS uses ACLs (or access control lists) to control file access. The standard Unix concepts of owner and group owner are retained, as well as the standard access bits for some backwards compatibility, but the access bits are almost completely ignored.

For efficiency reasons, under AFS the ACLs are only applied to directories. Some commands will allow you to give a regular file instead of a directory, but note that the ACLs only exist at the directory level and the ACLs affected are for the file's parent directory. To find out who can do what to a file, you need to look at the ACLs of its parent directory (and possibly the parent directory's parent directory, and so forth).

The basic way to do this is with the fs listacl command. The fs command is in /usr/afsws/bin which should be in your path. It's usage is fs listacl DIRECTORY, where DIRECTORY is the directory whose ACLs should be displayed. You can abbreviate listacl in the above with la. You will get a list of user and/or group names and there access under a heading Normal rights. (AFS also supports the notion of negative rights, but this is rarely used and beyond the scope of this document.)

For example, a typical home directory in Physics would have ACLs like:

Access list for /homes/someuser is
Normal rights:
system:imapmigration rlk
system:phys-managers rla
system:administrators rlidwka
someuser rlidwka

The left side are names of users and groups. The right side are the access permissions. The permissions can be broken down into two sets, one relating to the contents of the file itself, and one to the contents of the directory. The directory related rights are:

The file related rights are:

There are also a few aliases for some common access rights:

The groups listed in the ACL list are a special group created with the pts creategroup command. Generally they will have a colon (':') in the name, with the part to the left of the colon being the owner of the group. You can actually use the pts creategroup command to create your own groups over which you control the membership.

Groups beginning with system: are created by OIT and the AFS system. For the most part, you can ignore these, with two major exceptions:

Some other university related groups you may see:

Getting back to someuser's home directory, the ACL list

Access list for /homes/someuser is
Normal rights:
system:imapmigration rlk
system:phys-managers rla
system:administrators rlidwka
someuser rlidwka
this means

A typical groupspace directory for a person would look like

Access list for /group/somegroup/user/someuser is
Normal rights:
phys:phys-somegroup rl
phys:phys-somegroup-mgr rla
system:phys-managers rla
system:administrators rlidwka
someuser rlidwka

Here we see:

The members of the group system:administrators and the owner of the file both have implicit set ACL rights on the file. This cannot be removed with the fs setacl command.

One final note on interpretting AFS access rights brings us back to the traditional Unix access control bits. As stated earlier, they are almost completely ignored. Indeed, the bits for the group owner and the world/others are completely ignored. The bits for the user/owner field, are not ignored, and are applied on top of the AFS ACLs to determine the complete rights. This allows for some minimal file level granularity. E.g., if the AFS ACLs say you can write to a file, but the traditional access control bits do not allow writing by the owner the file, then you cannot write to the file. (Note that only the access control bits for the owner of the file are examined, whether you own the file or not.) This basically is not used often except to mark some files as executable.

ACLs of parent directories

Every directory in AFS has its own ACL list. When a directory is first created, it inherits the ACL list of its parent directory. Note that it gets a copy of the ACL list, and subsequent changes to the parent's ACL list will not alter the ACL of the subdirectory.

Also, regardless of what the ACL is on a directory, a person must be able to reach that directory before the ACL applies. Basically, this means that unless the directory is a volume and is mounted in multiple locations (if you do not undertand that clause, do not worry, it generally is NOT the case), you must have at least the l or list ACL on its parent directory to have any access to the directory.

For example, if I have a directory A with a child directory B and I grant you full access on B but no access on A, you can still not write into the directory B, or even read files in it. Indeed, but you do not have the list right on A, you cannot even see that B exists to see if you have permissions on it.

Commands for dealing with ACLS

Standard AFS Commands

Of course, having access control lists is useless without the means to manage them. Thus there are some special AFS commands for dealing with ACLS.

NonStandard AFS Commands

The following lists a number of scripts written in Physics to assist with dealing with ACLs. They are all located in /dept/phys/local/bin, which should be in your path. Unless otherwise stated, they may be specific to Physics departmental directory structure, any will not work elsewhere. Of course, they are only available in the PNCE-Unix or Glue cluster and are not a standard part of AFS.

Main Physics Dept site Main UMD site

Valid HTML 4.01! Valid CSS!