Skip to content Skip to site navigation

Setting Permissions with UNIX

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.

Overview

Access Control Lists -- known as ACLs (pronounced "ackles") -- determine who's allowed to see, change, or move your AFS files. The permissions you set with ACLs don't work on the files themselves: they work on the folders that hold the files.

These instructions presume you've got a SUNet ID and know enough about AFS to move around its directory structure. If you're uncertain about the latter, take a look at the Navigating AFS page. The first part links to instructions that tell you how to assure you're allowed to set ACLs in the first place. The second provides simple cookie-cutter instructions for which set of ACLs to use, depending on what kind of permissions you want to grant.

Get to your destination

If you're setting permissions in your home directory all you have to do is Log into Stanford Unix and then "cd" to your WWW directory. For the sake of example, however, we'll pretend below that your SUNet ID is "jdoe" and you want to set ACLs in a directory called "rocketscience" that's in the "dept" section of Stanford's AFS space. It would therefore be located at the end of the following directory path in AFS: /afs/ir/dept/rocketscience/. You'll use the "cd" command to get there. If this sounds like gobbledygook, take a look at the Navigating AFS page or just follow along: these instructions will still work.

  1. Log into Stanford Unix.
  2. Go to the directory where you'd like to set permissions.
    a) In this example, you'd type: 
    cd /afs/ir/dept/rocketscience/WWW/
    b.) You can always tell if you're in the right directory because the command prompt will be augmented with your present location. In other words, a command prompt that used to look something like this: 
    cardinal4:>
    shows your location in AFS like this: 
    cardinal4: /afs/ir/dept/rocketscience/WWW/>

Commonly used ACLs

This page tells you which ACLs to assign based on what you want to do. Don't forget to read the Tips and Tricks section of the Intermediate AFS Info page; it gives you real shortcuts for saving time when setting ACLs.

We'll presume that you're inside the folder or directory you want to set ACLs in, know that you possess the administrative privileges to do so and, for the sake of example, want to give ACLs to someone with the SUNet ID of "jsmith".

fs sa . system:anyuser lik
fs sa . system:anyuser lik
Look but don't touch (known as "Read" permissions) - Type:
fs sa . <sunetid> read
In our example, you'd have typed "fs sa . jsmith read" (don't forget the "space dot space" between "sa" and the SUNet ID). This lets people list your files, and open your files so they can read them, but prevents them from changing anything. It's the same as "fs sa . rl". Double check your work by typing "fs la": you should see "<sunetid> rl".
 
Almost total power (known as "Write" permissions) - Type:
fs sa . <sunetid> write
This is the most popular ACL. It lets someone work in your folder, change files, delete them, add new files, etcetera, but prevents them from letting other people into your folder(s). In our example, you'd have typed "fs sa . jsmith write" (don't forget the "space dot space" between "sa" and the SUNet ID). This is the most popular ACL. It's the same as "fs sa . rlidwk". Double check your work by typing "fs la": you should see "<sunetid> rlidwk".
 
Total power (known as "All" permissions) - Type:
fs sa . <sunetid> all
Be stingy when granting administrative permissions! The wrong person can wreak havoc in your and other directories. In our example you'd have typed "fs sa . jsmith all" (don't forget the "space dot space" between "sa" and the SUNet ID). It's the same as "fs sa . rlidwka". Double check your work by typing "fs la": you should see "<sunetid> rlidwka".
 
To kick someone out of a directory (this permission is called "None") - Type:
fs sa . <sunetid> none
In our example you'd have typed "fs sa . jsmith none" (don't forget the "space dot space" between "sa" and the SUNet ID). This removes all of a person's permissions for a directory, even if they had admin perms (rlidwka). Double check your work by typing "fs la": you should not see the SUNet ID of the person whose permissions you removed anywhere in the ACL list.
 
If you're an instructor and are having many students submit tests, papers, homework, etc. into a single directory, you'll want to prevent the files they submit from being altered once they're added to the directory, and also prevent students from accidentally reading or deleting other students' work. Type:
fs sa . system:anyuser lik
Don't forget the "space dot space" between "sa" and the word "system:anyuser", nor the colon in the word "system:anyuser". Double check your work by typing "fs la": you should see "system:anyuser lik".
Last modified April 12, 2023