AFS Access Control

Default Access Control for CSAIL

By default, anyone can see the names of files in your AFS Home Directory, but cannot read the files’ contents or write to your home directory. All directories beneath your home directory will inherit these permissions, unless changed.

This allows access to subdirectories that you may have shared out – in particular, the public_html/ directory that contains your personal web page.

If you don’t want ordinary users to see the names of your files, there are a couple of things you can do. One is to change the ACL so that only the web server can see inside your home directory. The other is to create a subdirectory that no one but you can see into, and put anything sensitive inside it. If you have any sensitive data in your home directory, hiding it this way is a good idea.

AFS Access Control

AFS associates an access control list (ACL) with each folder. Notably, AFS ignores most unix per-file permissions1. The ACL specifies permissions by user and/or group for a folder and the files within it. New folders’ permissions are copied from their parent folder when they are created.

In brief: from a unix shell (aka Terminal on Mac OS), the fs command is used for most modifications. It has a syntax of actionfs help will list all actions. (On Windows, right-click a directory AFS Access Control Lists… for similar functionality, or ssh to a CSAIL Linux host, eg [login.csail.mit.edul].)

fs listacl foo will list the ACL for the directory foo (or the current directory if foo is a file). ACLs are in the format:

      Access list for foo is
      Normal rights:
         system:administrators rlidwka
         system: anyuser 1
         testuser rlidwka

Here’s what it means:

Easier permission labels:

Recursively Changing ownership/permissions

The basic fs setacl command deals with only one directory at a time. To change permissions on a directory and all its subdirectories at once, use a CSAIL Linux host to run the fsr command (this command is not available by default on Linux, Mac, or Windows). For example, the following command grants read access to all members of the AFS group researchgroup. Predefined and custom groups are available; see AFS Protection Groups. (Additionally, if you are trying to run fsr on athena, you must first run add consult to gain access to the fsr command.)

testuser@login64:~$ fsr setacl . researchgroup read

Examples

To set up a home directory so that only the web server can see inside, first take away the default permission for system:anyuser to list files:

testuser@login64:~$ fs setacl . system:anyuser none
testuser@login64:~$ fs listacl .
Access list for . is
Normal rights:
  testuser rlidwka

…and then grant “list” ability back to the webservers (www group):

testuser@login64:~$ fs setacl . www l
testuser@login64:~$ fs listacl .
Access list for . is
Normal rights:
  www l
  testuser rlidwka

To create a private folder that nobody but you can see into:

testuser@login64:~$ mkdir private
testuser@login64:~$ fs listacl private
Access list for private is
Normal rights:
  system:anyuser l
  testuser rlidwka
testuser@login64:~$ fs setacl private system:anyuser none
testuser@login64:~$ fs listacl private
Access list for private is
Normal rights:
  testuser rlidwka

  1. “Notably, AFS ignores most unix per-file permissions:” The owner bits rwx are applied to anyone who is granted access via the ACL. For most users, this means they can be ignored, with the exception of chmod +x to make something executable. Most ownership is also ignored, with the exception that the owner of a volume (for example, the unix-style owner of /afs/csail/u/e/example) automatically has a access to every subdirectory of the volume. ↩︎