AFS Access Control and Security

Authentication

Authentication is the responsibility of Kerberos.  Keep your ECE Kerberos password private and strong.

Authorization

The other component of Access Control is authorization. Access Control Lists (ACLs) are used to control who has and does not have permission to read and write your files.

AFS space for ECE users is at /afs/ece/usr/<username> and by default has this ACL:

$fs la /afs/ece/usr/<username>
Access list for /afs/ece/usr/<username> is
Normal rights:
 system:administrators rlidwka
 system:authuser l
 system:anyuser l
 <username> rlidwka

The access control letters are:

  • r    Read: User can read files.
  • l    List: User can get a list of files in the directory. Required for user to cd to that directory.
  • i    Insert: User can create files in a directory.
  • d    Delete: User can delete files from a directory.
  • w    Write: User can modify existing files in a directory.
  • k    Lock: User can put an advisory lock on files in directory.
    • AFS does not support full file locking; and therefore, it should not be used for purposes that enable multiple processes to access the same files.
    • You generally shouldn’t have to worry about this issue.
  • a    Administer: User can change rights for self or others.
    • Don’t grant or give this one away lightly.

Unlike unix file permissions, ACLs apply at the directory level, not at the file level.

Security (ACLs) for Home Directories

The most common mistake with ACLs is about security. If you have files that contain data that you do not want to be available to anyone in the world who looks, you must ensure that you set suitable ACLs on the directories that contain those files.

Some applications write and look for configuration files in your home directory and will search only there. These files are often called dotfiles because they are often prefixed with a dot so that they are hidden from an ordinary directory listing. If these files are not available in your home directory, you will lose any custom settings for preferences or options for that application.

Sometimes, however, these types of files may contain sensitive information that you do not necessarily want available to anyone who looks. You can reconcile these issues by moving your sensitive dotfiles to your ~/Private directory, placing appropriate ACLs on this directory (so it can only be seen by you as authenticated with an AFS token by the kerberos system), and by making links from your home directory to the ~/Private location.

Example:

I want to ensure that my mail directory (that one of my applications uses to store mail locally) and the directory that Mozilla Firefox, my web browser, uses to store all its data including cookies, bookmarks, history, etc. are private and secured against unauthorized access, but that they are available from my home directory.

$ls -a ~
bin
Desktop
mail
.mozilla
OldFiles
Private
Public
public_html

$mv mail Private/mail
$mv .mozilla Private/.mozilla
$ln -s ~/Private/mail
$ln -s ~/Private/.mozilla

Please note that the login procedure requires that system:anyuser have rl rights to your home directory. If you revoked that priviledge, then the system thinks you have no home directory, and defaults to “/”. To correct that problem, run this command:

fs sa /afs/ece/usr/<username> system:anyuser rl

Commands to set ACLs

Many directories, by default, come with the following ACL:

$ fs la
Access list for . is
Normal rights:
  system:administrators rlidwka
  system:authuser l
  system:anyuser l

If it is a home directory, it probably also has a line like:

 <username> rlidwka
  • system:anyuser allows anyone who has access to AFS (worldwide) the specified access permissions whether they have AFS/Kerberos credentials or not.
  • system:authuser allows anyone who has an AFS token for the local realm (i.e. a token @ECE.CMU.EDU) the specified access permissions.
  • system:administrators means just the ECE system administrators. If you remove their rights, then your home directory and its contents might not be backed up.
  • system:ece means any machine with an ECE owned IP address.

Setting ACLs is done using the setacl (sa) subcommand from the fs command suite:

$ fs help sa
  fs sa: set access control list (alias for setacl)
  Usage: fs sa -dir <directory>+ -acl <access list entries>+ [-clear] [-negative] [-id] [-if] [-help]
  Where: -clear     clear access list
         -negative  apply to negative rights

You can set an ACL that grants full access to you and removes all non-you access with a command like this:

$ fs sa -dir /afs/ece/usr/<username>/test -acl <username> rliwdka -clear

Sharing files with others

If you want to create additional directories that only certain other people, like your TA and lab partner, can look at, then you can do the following:

$ mkdir ~/322
$ cd ~/322
$ fs sa . <labpartner-id> rlidwk
$ fs sa . <myTA-id> rl
$ fs sa . system:anyuser none

What do you do if you have already created a set of directories that need to be updated so they can be shared with your lab partner? You can use the following command to find all subdirectories of the present working directory, and to update the ACL on each of these subdirectories in turn:

$ find -type d -print0 | xargs -i --null fs sa {} <labpartner-id> rlidwk

ACLs on your ‘public_html’ directory

If you would like to serve pages from your space but don’t want to give the world the ability to crawl through your directory tree, you can grant access to only the webserver by issuing the following command:

fs sa -dir /afs/ece/usr/<username>/public_html -acl system:anyuser none -acl system:authuser none -acl system:webserver-users rl

This does not eliminate the ability of the webserver to serve directory indexes, however, so take care!

PTS

PTS is the system that AFS uses for keeping track of users and groups. Each AFS user has a unique ID in the pts database.

When you issue the fs la command the output will look something like this:

$ fs la
Access list for . is
Normal rights:
  opr rlidwka
  system:administrators rlidwka
  system:authuser rl
  system:anyuser rl

Entries that contain a colon (:) are pts groups.

The pts command and it’s options allow you to control groups. The basic set of commands are:

  • pts createg – creates a group. The command should take the form of pts createg <owner>:<groupname> <owner>, for example, “pts createg opr:example opr”
  • pts add – adds a user to a group. “pts add joe opr:example”
  • pts remove – remove a user from a group. “pts remove joe opr:example”
  • pts members – this command gives different results depending on whether you provide a user or a group id as a parameter. If you provide a user, it will display a list of all the groups of which the user is a member. If you provide a group id, it will display a list of all the members of that group.
  • pts delete – delete a group. You must be the group owner to delete a group.

Once you have created a pts group, you can assign ACLs to directories for that group using the same process that you would for an individual user.

Many times groups allow you to manage access to directories more easily than using user ids directly. Rather than having to add/remove individual users to directories, you can add groups and then add/remove users to the groups. This is usually much easier than trying to make sure that you have made the change on every directory in a tree.

This entry was posted in Data Storage. Bookmark the permalink.