TWiki > TIG > FileSystemsAndBackups > AFSIntro

Introduction to the CSAIL AFS Cell

Scope

This page is a general overview of AFS services at CSAIL. Instructions for configuring specific operating systems to access the AFS cell will be forth coming for at least:

  • GNU/Linux
  • Mac OSX (10.3)
  • WindowsXP

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 V2 with Kerberos authentication (either via a valid ticket or by entering your Kerberos password when prompted).

Differences from NFS

The reason AFS was chosen over NFS for implementing a shared network file system is because of its security model. Users authenticate to the file system using Kerberos rather than assigning permissions based on a locally assigned UID. One of the classic security flaws in NFS is that root must be trusted on all systems that mount the NFS share because root can assume the UID of any user. AFS eliminates this.

AFS also 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 is that AFS has a different permissions model. Permissions are applied as Access Control Lists (ACLs) per directory not as Unix Mode Bits per file. This means that all files in a given directory have essentially the same permissions. The exception is that you can remove write permissions on a per file basis using the standard Unix 'chmod -w >filename<'

Since AFS does not use Unix permissions or file ownership, your files may look like they are owned by someone else or have permissions that don't make any sense when you do an 'ls -l.' Don't worry. AFS knows who the proper owner is.

If you are having trouble reading or editing your files, it is not because they appear to be owned by someone else. It is probably because your AFS tokens have expired. You can fix this by typing "renew" at any shell prompt.

Default Access Control for CSAIL

When your home directory is set up, anyone can see the names of files in your home directory (except for dotfiles), but cannot read the files or write to your home directory. All directories beneath your home directory will inherit these permissions.

The reason for setting up ACL's this way is that if users cannot see items in your directory, they cannot see subdirectories either. This is particularly important for web service. If the web server cannot see your public_html directory, nobody will be able to see your web pages.

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 use your CSAIL account for on-line banking and have any financial data in your home directory, hiding it this way is a good idea.

Information about setting up ACL's is below.

AFS Access Control

AFS provides for allowing and denying permissions on a per user basis and allows users to create their own groups that can be used in ACLs. Multiple users and groups may be specified. This gives much greater granularity that the Unix convention of files having exactly one owner, one associated group (which must be defined by an administrator) and then everyone else.

Managing ACLs is detailed on the OpenAFS website but here are some quick examples (note that fs is the command used and has a syntax of fs action; fs help will list all actions):

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
         jon rlidwka
Here's what it means:
  • r: read the contents of files in the directory
  • l: lookup files in the directory (also allows listing the directory)
  • 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

Thankfully, you don't need to type that to set permissions...

  • fs setacl foo brooks read gives the user brooks read access
  • fs setacl foo brooks write gives the user brooks read and write access
  • 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 (change ACL) permissions

To set up a home directory so that only the web server can see inside: 

lpb@locutus:~$ fs setacl . system:anyuser none
lpb@locutus:~$ fs listacl .
Access list for . is
Normal rights:
  lpb rlidwka
(I took away permissions for system:anyuser to list my directory.) 
lpb@locutus:~$ fs setacl . www rl
lpb@locutus:~$ fs listacl .
Access list for . is
Normal rights:
  www rl
  lpb rlidwka
(I gave permissions for the web server to read and list my home directory, so it can see public_html.)

Here's how to create a private folder that nobody but you can see into: 

lpb@locutus:~$ fs listacl .
Access list for . is
Normal rights:
  system:anyuser l
  lpb rlidwka
lpb@locutus:~$ mkdir private
lpb@locutus:~$ fs listacl private
Access list for private is
Normal rights:
  system:anyuser l
  lpb rlidwka
(See that the new directory is created with the same permissions as the parent directory.) 
lpb@locutus:~$ fs setacl private system:anyuser none
lpb@locutus:~$ fs listacl private
Access list for private is
Normal rights:
  lpb rlidwka
(I've listed the ACL's for this directory to prove that they are set correctly.)

Recursively Changing ownership/pemissions

There is no "built-in" recursion in the fs setacl command, but it's easy to recursively change the ACL of a directory and its subdirectories. First, cd into the parent directory whose ACL and all children ACLs you want to change.

Next, issue the following command: 

find . -noleaf -name .snapshot -prune -o -type d -exec fs sa {} <user/group> <permission> \; -print
where <user/group> is the user or group that you want to add/alter, and <permission> is the permission keyword (e.g., read, write, all, none) or string (e.g., l) you want to enforce. Do not leave out the \; — without it, the command will fail.

Filesystem Layout

The root of the AFS file systems is /afs; the next level is the cell name. 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. An additional level based on the first letter of the user name is inserted to make directory listing more manageable. 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.

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 September, '07, there are 20 AFS fileserver online, and three 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

Supported Platforms

  • Macintosh OS X 10.3 (prior versions of OS X not supported; email us if you need installation media for Mac OS 10.3)
  • Microsoft Windows XP (prior versions of Microsoft Windows not supported; email us if you need installation media for Microsoft Windows XP)
  • GNU/Linux