Introduction to the CSAIL AFS Cell

Public Access

The CSAIL AFS cell is available on any system with AFS software installed and an internet connection. For the convenience of lab members TIG runs a public login machine login.csail.mit.edu with AFS configured. Access is via SSH (either via Kerberos tickets or by entering your CSAIL Kerberos password when prompted).

Background

AFS was chosen for implementing a shared network file system primarily because of its security model. More at Why AFS AFS transmits data encrypted over the network and does caching on local disk to speed subsequent access.

The most obvious difference to the user from NFS or other unix filesystems is that AFS has a per-directory permissions model. See the next two sections for more.

Filesystem Layout

Beneath /afs/csail.mit.edu are the following directories:

  • common: Shared files useful on multiple architectures. Currently this only includes configuration example files. In the future it could contain multi-platform scripts and licensed software that runs on multiple platforms
  • u: User home directories are stored under this hierarchy. All CSAIL users with a Kerberos principal and INQUIR database entry have an AFS home directory. The initial quota on home directories is 20GB. If your research requires more personal storage than this, please contact help@csail.mit.edu
  • group: Contains data shared between members of a research group. If other members of your group use data stored in your personal home directory, it's probably a good idea to move it into the group directory instead. We've found this helps with personnel transitions (for example if you go and graduate or something)
  • proj: Contains shared data for projects that cross reearch-group boundaries.
  • @sys: There is not actual @sys subdirectory; @sys is translated into the local host's architecture and operating system (e.g., i386_linux26). Directories named after the output of this command are used to hold operating system and architecture specific binary files.

Trouble reading or saving files?

If you suddenly lose access to files in AFS, your AFS tokens probably have expired. You can renew your tokens by running aklog if you have current Kerberos tickets, or by running kinit && aklog if you don't have a Kerberos ticket, or if your Kerberos ticket is also expired.

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 permissions[1]. 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 fs action; fs help will list all actions. (On Windows, right-click a directory -> AFS -> Access Control Lists... for similar functionality, or ssh to a CSAIL Debian host, eg login/64.csail.)

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:
  • r: read the contents of files in the directory
  • l: list files within the directory (required to access a subdirectory)
  • i: insert (create) files into the directory
  • d: delete files from the directory
  • w: write (or modify) files into the directory
  • k: lock (or modify the write-mode bit) of files in the directory
  • a: administer or change the ACL of the directory

Easier permission labels:
  • fs setacl foo brooks read gives the user brooks read access, = rl
  • fs setacl foo brooks write gives the user brooks read and write access, = rlidwk
  • fs setacl foo brooks none removes all access for the user brooks
  • fs setacl foo brooks all gives the user brooks read, write, and administer permissions, = rlidwka

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

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 Debian host to run the fsr command (this command is not available by default on Ubuntu, 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

Interoperating with Athena AFS

CSAIL has established a trust relationship with the athena.mit.edu AFS cell so that Athena users can be put on CSAIL ACLs and vice versa. More details here.

Physical Implementation

The CSAIL AFS cell runs on a variety of hardware and is constantly changing. As of June 2010, there are 29 AFS fileservers online, and 3 dedicated AFS database servers. More hardware is maintained in a state where it can easily be brought online to replace a failing server or to add capacity.

Related Links

Footnotes

[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.
Topic revision: 14 Apr 2014, StephenJahl
 

MIT Computer Science and Artificial Intelligence Laboratory

 

  • About CSAIL
  • Research
  • News + Events
  • Resources
  • People

This site is powered by Foswiki MIT: Massachusetts Institute of Technology