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 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
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 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.
fs command is in /usr/afsws/bin which should
be in your path. It's usage is
fs listacl DIRECTORY,
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
For example, a typical home directory in Physics would have ACLs like:
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
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
A typical groupspace directory for a person would look like
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.
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.
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.
fs listacl DIRECTORY: This command displays the ACL list for the named
DIRECTORY. You can abbreviate
la. If you provide a regular file instead of a directory, it will display the ACLs for the directory containing the file (remember, regular files do not have ACL lists). If you specify a directory not in AFS, you will get an error.
fs setacl -dir DIRECTORY -acl USER ACCESS: This command modifies the ACLs on the directory
DIRECTORY. If no access rights are defined for the user or group
USER, then an entry is added and set to
ACCESS. If an entry exists for
USER, it is changed t
ACCESScan be any combination of the access codes r, l, i, d, w, k, a or the special words all, write, read, or none. Note that by default the
fs setaclcommand does not alter any access rights not given on the command line. You can supply multiple directories or multiple user/access pairs. To delete an entry for a specific user or group, issue an
fs setaclcommand with
ACCESSset to none.
fssuite of commands has a few other subcommands, like
copyaclthat may be of use. Use the
helpsub command for more information.
ptssuite of commands has a number of subcommands useful for managing pts groups. This allows you to define your own groups of users, e.g. myusername:friends which you can then use in your ACL lists.
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.
setacl_tree DIRECTORY USER ACCESSsets the access rights as specified on the directory
DIRECTORYand recursively on all of its subdirectories. It basically does
fs setacl(which, remember only works on the named directory, and not subdirectories thereof) recursively on all directories starting at
DIRECTORY. Only one top directory can be given, but multiple user/access pairs can be given. If you are concerned about whether the recursion goes from root down or from leaves up, you can use the
setacl_downtreevariants. This script is not constrained to Physics directory structure.
make_private_dir DIRtightens the access rights on the directory
DIRso that only you and system staff have any access (and system staff access requires an ACL change first). This will work in your home or group space. The related script
make_private_tree DIRdoes the same, but acts recursively on
DIRand its subdirectories.
make_group_readable_dir DIRmodifies the ACLs on directory
DIRso that it is readable by members of your research group, but no one outside your research group. Only you (and system staff and designated group computer contacts) have write access. The variant
make_group_readable_tree DIRacts recursively on the named directory and its subdirectories. These scripts only work on directories in group space.
make_public_dir DIRmodifies the ACLs on directory
DIRso that it is readable by anyone with valid AFS tokens in the GLUE.UMD.EDU domain. Basically, this means anyone with a Glue account. Write access is limitted to you (and system staff and designated group computer contacts). The variant
make_public_tree DIRacts recursively on the named directory and its subdirectories. These scripts only work on directories in group space.