PNCE User Intro to AFS ACLS

PNCE User Documentation

Introduction to AFS Access Control Lists

• Traditional Unix Filesystem Access Control
• AFS Access Control
• ACLs of parent directories
• Commands for dealing with ACLS

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

• rwx: indicates that the owner (joe) can read, write, and execute the contents of the file.
• r-x applies to the owning group, and means that members of the group users can can read and execute the file, but not write to it.
• The next three characters --- apply to everyone else, and in this case means any user other than joe and not in the users group (and not root) has no access to the file.

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:

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:

• l for the right to list the names of files in the directory. You must have at least the 'l' right on the parent directory to access a subdirectory (even if you have full permissions on the subdirectory).
• i the right to insert a file in the directory, or basically the right to create a new file
• d the right to delete a file in the directory
• a the right to change the ACL list. Any user or group with this right can basically do anything they want to the file. Although this right does not directly grant any other rights (e.g. delete), anyone with this right can grant any other right to themselves. Still, it is sometimes useful to only grant the a right, in that without any other rights a two step process (grant the right, than use the right) is required to do anything else. PCS often only grants itself this right to reduce the likelihood of accidents.

The file related rights are:

• r for the right to read the contents of the file
• w for the right to write or modify the contents of the file.
• k the right to place a lock that file

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

• all refers to all rights, ie rlidwka
• write refers to the standard write access rights, i.e. rlidwk
• read refers to standard rights for reading a file, i.e. rl
• none refers to no rights whatsoever. This is particularly useful when deleting 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:

• system:authuser refers to anyone logged onto the system with valid AFS tokens for the Glue domain. I.e., it means anyone with a Glue account in the PNCE-Unix/Glue clusters.
• system:anyuser refers to anyone with access to AFS, which generally means the whole world. Note that they do not need to have a Glue, Wam, or other university account. A hacker on the other side of the world with a linux box and a network connection. This group also applies to long running jobs or cron jobs, etc. that either never had tokens or their tokens expired. Note: this group is VERY public. Do not give it write access, and only give it read access for files you want to make public to the world (e.g. public web pages).

Some other university related groups you may see:

• system:administrators: these are the OIT systems staff. This is a special group, and they actually will have full rights to your directory even if you delete the ACL. Basically, the AFS equivalent of the root user.
• system:phys-managers: this is the PCS systems staff.
• phys:*: anything starting with phys is a PCS group.
• phys:phys-GROUP: everyone in the research group GROUP
• phys:phys-GROUP-mgr: the officially designated computer contact people for the research group GROUP

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

• the user himself has full rights
• OIT system staff have full rights
• PCS staff have read and set ACL rights. The set ACL right means that effectively we have full rights (i.e. we can grant ourselves full rights) but to do anything beyond reading requires two steps. This limits the damage that could be done by an accident.

A typical groupspace directory for a person would look like

Here we see:

• OIT system staff and the user have full rights
• PCS staff have read and set ACL rights
• The designated computer contacts for the group have read and set ACL rights
• Members of the research group somegroup have read access

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.

• fs listacl DIRECTORY: This command displays the ACL list for the named DIRECTORY. You can abbreviate listacl by 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 ACCESS. ACCESS can 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 setacl command 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 setacl command with ACCESS set to none.
• The fs suite of commands has a few other subcommands, like copyacl that may be of use. Use the help sub command for more information.
• The pts suite 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.

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.

• setacl_tree DIRECTORY USER ACCESS sets the access rights as specified on the directory DIRECTORY and 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_uptree and setacl_downtree variants. This script is not constrained to Physics directory structure.
• The script make_private_dir DIR tightens the access rights on the directory DIR so 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 DIR does the same, but acts recursively on DIR and its subdirectories.
• The script make_group_readable_dir DIR modifies the ACLs on directory DIR so 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 DIR acts recursively on the named directory and its subdirectories. These scripts only work on directories in group space.
• The script make_public_dir DIR modifies the ACLs on directory DIR so 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 DIR acts recursively on the named directory and its subdirectories. These scripts only work on directories in group space.