Skip to content Skip to site navigation

More about Permissions

To increase security and reduce risk, Stanford is sunsetting its WebAFS service that is used to upload and download files to AFS.

To optimize AFS and make sure it is serving its intended functions, UIT has also taken these actions:

  • UIT no longer automatically provisions new faculty and staff members with AFS user volumes. New faculty or staff who need a personal user volume must submit a Help request.
    • This change does not impact existing AFS directories or the process for adding permissions for new individuals to those existing directories. Your existing space and everything in it remains intact.
    • This change does not impact the auto-provisioning of new AFS user volumes for students and postdocs.

​Class volumes do not expire and are kept indefinitely. This is an official academic policy, and any change to this policy must be considered by the Faculty Senate.

AFS File Permissions
 

Setting strict ACLS

  • To let a person change some files, but not add, delete, or create new ones, type:
    fs sa . <sunetid> rlwk
    In our example you'd have typed "fs sa . jsmith rlwk" (don't forget the "space dot space" between "sa" and the SUNet ID). Double check your work by typing "fs la": you should see "<sunetid> rlwk".
     
  • To let someone change files, plus add or create new ones, but not let them delete files (to prevent accidents), type:
    fs sa . <sunetid> rliwk
    In our example you'd have typed "fs sa . jsmith rliwk" (don't forget the "space dot space" between "sa" and the SUNet ID) . This set of ACLs also lets people create new sub-directories. Double check your work by typing "fs la": you should see "<sunetid> rliwk".
     
  • To let a person or computer system see what's in your directory (i.e., list its contents), but not let them read the files in that directory, type:
    fs sa . system:anyuser l
    That's an "l", as in "list", not the number one ("1"). Don't forget the "space dot space" between "sa" and the word "system:anyuser", nor the colon in the word "system:anyuser". This ACL, one of the most common, is a bit more restrictive than "fs sa . rl". The "rl" is very common because, without "r" (which stands for "read"), and "l" (which stands for "list"), neither people or computers can do much with the files in the directory. In fact, "l" by itself is a prerequisite for all other ACLs. Double check your work by typing "fs la": you should see "system:anyuser l".
     

Tips and tricks

  • New sub-directories inherit the permissions of the parent directories they came from.
    This means that whenever you create a sub-directory you don't have to create a new, identical set of ACLs from scratch. On the other hand, if certain people with access to the parent directory need to be excluded from the sub-directory, you'll have to remember to remove them (as well as add anyone who doesn't have permissions for the parent directory but needs them in the sub-directory).
     
  • Use fsr to set ACLs on many sub-directories at once.
    The "fsr sa" command (as opposed to "fs sa") will duplicate whatever ACLs you set on a parent directory in every sub-directory of that parent directory, and then every sub-directory of every sub-directory, etc. The "r" in "fsr" means "recursive". This command is a time-saver, but be careful ... you might be giving or removing permissions to sub-directories in ways you hadn't thought of.
     
  • Directories can only hold up to 20 ACLs at a time.
    If there are lots of people who need access to your directory, you can put them all together in a group so they count as only one ACL. Learn how to create pts groups.
     
  • The dot in the "fs sa . <sunetid>" commands stands for "this particular directory".
     

The Access Control List (ACL)

Under AFS, permissions are set by directory, not by file. Every file in a directory has the same permission. New sub-directories inherit the permissions of the parent directories they came from. A directory's permissions are contained in the Access Control List (ACL). An ACL may have up to twenty entries, but if you create a "pts" group that has 20, 30, or 40 people in it the whole group will only count as one entry.

You can create many different types of permissions by combining the seven basic permissions below in different ways.

l -- Lookup

Lookup is the most basic of all AFS file permissions. People who have Lookup privilege on a directory can obtain two things: (1) the ACL settings for that directory, and (2) a list of the contents of that directory.

The AFS file system uses Lookup privilege on behalf of users to determine which privileges a particular user has for that directory. This means that Lookup access is required for any of the other AFS file permissions to work as expected.

Another consequence of this is that, in order to give someone broader access to a subdirectory, that person must also be given Lookup access to all of that subdirectory's parent directories.

r -- Read

People who have Read privilege on a directory can read or execute files in that directory, or copy files from that directory to someplace else.

i -- Insert

People who have Insert privilege on a directory can create new files and subdirectories within that directory.

d -- Delete

People who have Delete privilege on a directory can delete files and empty subdirectories within that directory.

w -- Write

People who have Write privilege on a directory can modify the contents or attributes of any pre-existing file in the directory (e.g. they can use chmod to make a file executable).

k -- Lock

People who have Lock privilege on a directory can obtain an advisory lock on a file within that directory; having this lock helps ensure that no one else accidentally changes that file while one person is making modifications to it. This is the equivalent of flock(); it does NOT provide a mandatory lock.

a -- Administrative

People who have Administrative privilege can modify the ACL on that directory in any fashion -- they can add or delete privileges for specific users, or they can add or delete users or groups from the ACL.

NOTE: read, write, lock, insert, delete, and administer permissions all require lookup permission. The filing system cannot tell what file permissions the user has without lookup privilege. Similarly, users cannot access a subdirectory unless they have lookup privileges for ALL its parent directories.

Last modified April 12, 2023