Skip to main content

Intermediate File Permissions and ACLs

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.

Useful AFS and Unix commands

Once you know how to set permissions and list files you'll want to know additional commands so you can make new directories, copy files, etc. Each of the basic commands you learn also come with a variety of sub-options. For example, to list the contents of a directory you'd type "ls", but if you wanted to know which items in the list were files and which ones were sub-directories, you could type "ls -F", which marks sub-directories with a slash at the end. That kind of stuff.

  • Learn more commands via the web

    To learn more about AFS and Unix commands, take a look at the Unix Command Summary document.

  • Learn more about commands online

    You can often get more information about an AFS command by adding a "help argument" or "flag" to the command while at the command prompt. For example, if you wanted more information about the "fs" command:

    To get a list of fs subcommands, type:

    fs help
    To get a somewhat cryptic syntax list for a subcommand, you can type:
    fs [subcommand] -help
    To get a look at the rather worthless online manual concerning "fs", type:
    man fs
    Press the space bar to page down through the text. Press "q" to get out of the manual pages. You might notice that the information seems rather poorly presented. This is usually the case with manual pages, but the "man" command can sometimes unearth extremely useful stuff or help you figure things out.

Tokens: your ticket to AFS

When you login to your Stanford Unix account you obtain a "token" that tells the computer you are who you say you are. This token has a lifetime of 25 hours. If your token expires you're placed into "system:anyuser" status and lose access to your private directories.

To check if you have a token, type:

tokens

To obtain a new token, type:

klog

This will prompt you for your password and obtain a new token for you. If your username and AFS username are different, then use klog -x [afsusername], where [afsusername] is your AFS username.

If you have trouble finding these commands, they should be located in the directory /usr/pubsw/bin.

For more information about tokens, read the Kerberos section.

Account Setup

When you get a SUNet ID you automatically get a Stanford Unix account. This account comes pre-configured with list privileges (system:anyuser l) on all your directories except your private directory, your web directory, and your Mail directory. Permissions for these vary slightly.

This section tells you how to setup your dot files (.rhosts, .plan, .project), create public directories, and increase both account security and openness.

Creating A Public Directory for Config and Other Files

A public directory is the most secure way to store your .plan, .project, .klogin, and other files that need to be --or you wish to be--world-readable:

cd ~
mkdir public This directory may already exist
fs setacl public system:anyuser read

The cd command takes you to your root directory. The mkdir creates a public subdirectory. The fs command gives read permission to the subdirectory.

Now you can make files public. For example, to make your .plan file readable, type:

cd
mv .plan public/
ln -s public/.plan

The mv moves your .plan file to the now world-readable subdirectory. The ln creates a "symbolic link" from the file public/.forward to your root directory.

You can do the same for your .project, and .klogin files, if you have them.

NOTE: .forward and .rhosts files do not work on the Stanford Unix system. To forward your mail you must use the StanfordYou web page. Use a .klogin file to allow kerberized rlogin or rsh from one Stanford Unix host to another. For example,

cd ~$USER/
mv .plan .project .cshrc .login .rhosts .dotfiles/
ln -s public/.plan
ln -s public/.project
ln -s public/.klogin

Creating Public, Project, and Friends Directories

  1. Setting Up Your Directories

    One of the powers of AFS is its file permissions (see section 1.1 for an overview). You can grant permissions to individual users or groups. Since AFS permissions are by directory, you only need to setup the permissions on the directory and its existing subdirectories. Files inherit the permissions of their directory. New subdirectories inherit their parent directory permissions.

    In order for someone to access a subdirectory, at least list (l) permission MUST be given on every parent directory of the subdirectory.

  2. Creating a Public and/or Web Subdirectory

    You may already have a public directory in your account. In case you don't here are some examples commands that will create one for you

    cd
    mkdir public
    fs sa public system:anyuser read

    The cd command moves you to your root directory. The mkdir command creates a directory named pub. The fs command makes the directory readable for any user.

    Any subdirectories that you create in pub will also be public (since newly-created subdirectories inherit the permission of their parent directory). If you move a directory into this directory or use a symbolic link, however, you may need to adjust the permissions.

  3. Public Insert Directories

    Directories which provide insert privileges for anyone are a security hole. Anything added to this directory applies to your quota, so you need to watch the directory.

    If you do setup such a directory, it needs a minimum of system:anyuser li. It should have at a maximum system:anyuser rliw.

    If you use a subdirectory that someone added to your insert directory, be sure to change the file permissions back to system:anyuser none and to what it should be (public directories should have system:anyuser read).

  4. Project or Friend Directories

    Suppose you are working a project with curley and moe. Here's some commands that will create a project directory:

    cd ~$USER
    mkdir stooge
    fs sa stooge curley write
    fs sa stooge moe write

    The cd command moves you to your root directory. The mkdir command creates a project directory named stooge. The fs commands give users curley and moe write to that directory. (Be sure that you do not go over quota!) If you want others to be able to read the files, you can use:

    fs sa stooge system:anyuser read

    If you do not want them to have any access, use:

    fs sa stooge system:anyuser none

    For a final example, suppose you are going to be creating five subdirectories: public, private, moe, curley, and larry. Since the names should be obvious, here's how to set them up:

    1. Put list on the root project directory (stooge). This is required to allow users to get to stooge/public:
      fs sa stooge system:anyuser l
    2. Create the public directory and make it world-readable.
      cd stooge
      mkdir public
      fs sa public system:anyuser read
    3. Now create the private directory.
      mkdir private
      fs sa private system:anyuser none
    4. Now a directory to contain details of pranks to be pulled on curley:
      mkdir moe
      fs sa moe curley none
      fs sa moe system:anyuser none

      And on moe:

      mkdir curely
      fs sa curley moe none

      And on both of them:

      mkdir larry
      fs sa larry moe none curley none

      And finally, let us strip system:anyuser from these directories:

      fs sa -dir larry curley moe -acl system:anyuser none
Last modified