AFS uses authentication and authorization as its primary security techniques to ensure that files are accessed only by authorized users. Whenever you login to UNIX, AFS checks the password you supply to make sure that you are who you say you are. If you are, AFS grants you a token and thereby authenticates you as a valid AFS user and logs you into UNIX.

Authorization determines what actions you may or may not perform on AFS files via the Access Control List (ACL) mechanism. This mechanism is based on authentication. AFS Access Control Lists which are discussed in detail in AFS File Protection: Access Control Lists and Protection Groups

A token identifies you to AFS and is used as the AFS file server and the client machine work together to give you access to your files. Without it, your access will be limited. After you have established a UNIX account, whenever you login to UNIX you will automatically be given a token except under certain limited circumstances when issuing the ssh (secure shell for remote login to SLAC hosts) command.

You will have only one token on each machine at SLAC to which you log on, but may have additional tokens for foreign (that is, non-SLAC) machines that run AFS. A SLAC token expires after 25 hours of being continuously logged in to UNIX and may be renewed with the klog command. The tokens command shows whether or not you have a token(s).

A token, stored by the cache manager, is usually associated with one logon session on one host computer. If you’re using X Windows on a workstation, you need to authenticate once on that system. Then you can open as many windows with that AFS token as you want. However, if you then ssh (that is, log on to another system remotely from your workstation) to another host system, in most cases you must authenticate again to get a token on that system.

Many people wonder: when do I have a token? when don’t I? The answer is:

• If a task has a token, all its subtasks will have a token.
• At logon, everything you run on the computer to which you’ve logged on will share that token.
• When you connect to another machine, you may or may not have a token. The most reliable way of finding out is to use the tokens command.

See Authentication_Commands for details on the commands tokens, klog, and unlog.

/afs/slac/u/sf/ilse

The cache manager is a process that requests data on your behalf from the server machines and stores a copy on your machine. You then work on the copy which reduces the number of network requests to the server. When you (or someone else) closes or saves the file, the changes to the file are transmitted to the server. There is one cache manager for each client machine, such as yours.

For various reasons we like to keep individual volumes under 500MB. If your home directory is larger than this, we prefer to split it into multiple volumes. Other than finding a convenient subset into which to split your subdirectories, this will have no effect on the use of your home directory.

If you fill up your initial quota, use the space request form to request an increase. See also the Web page on disk space policy.

The command:

command help

To get help on a specific subcommand, type:

command subcommand -help

Examples:

The help entry lists the subcommand’s arguments in the prescribed order and its flags.

If you are trying to do something and don’t know the AFS command, try:

command apropos -topic "help-string"

ilse@odysseus $ fs apropos -topic "access control"
cleanacl: clean up access control list
copyacl: Copy access control list
listacl: list access control list

To see the tokens you are currently holding, use the tokens command. For example:

ilse@odysseus $ tokens
Tokens held by the Cache Manager:

User's (AFS ID 1616) tokens for afs@slac.stanford.edu [Expires Jun 13 09:12]
--End of list—

If you do not have a token, you will see:

Tokens held by the Cache Manager:
--End of list--

ilse@odysseus $ klog
Password:your AFS password
ilse@odysseus $

Here is an example in which user bobcook, who has an account in foreign cell ir.stanford.edu, gives the klog command to obtain a token in that cell. With the klog command he must identify himself (bobcook) and specify the cell name in which he wants to be authenticated (ir.stanford.edu).

User bobcook gives the tokens command to verify that he has been authenticated. Note that he now has two tokens: one for the foreign cell and one for SLAC.

A list of foreign cells known to your cache manager is given in the file /usr/vice/etc/CellServDB, which is updated occasionally based on the list maintained by the OpenAFS vendor.

/afs contains the names of all AFS cells and it can take a very long time to collect them all. Therefore, don’t do cd /afs followed by ls -F, which is the default alias for ls, or an ls -l. Instead, do a /bin/ls.

You can set and modify the ACL on your directories with the fs setacl command. ACLs control who may access files and directories. More specifically, they control who may see the names of files in a directory; read, write, delete, or move a file; add or copy new files or directories; and change the ACL.

When you create a subdirectory, it assumes the ACL of the parent directory. However, you can modify the ACL for the subdirectory independently after you have created it. But, if the parent directory has a more restrictive ACL than the child, other users might be denied some of the access rights you granted them in the child. Always provide lookup access in the parent directory for someone who has permissions in the subdirectory.

To give you a sense of what an ACL looks like, let’s look at the one for a typical directory, /afs/slac/u/sf/ilse:

• system:slac includes any user of a host connected to the SLAC local area network. Permissions granted are read and lookup.
• system:authuser includes any user authenticated in the SLAC cell (that is, the user must have an AFS token). Permissions granted are read and lookup.
• system:administrators includes SLAC AFS system administrators. Permissions granted include read, lookup, insert, delete, write, lock, administer (that is, write, add, and delete files as well as change the ACL for the directory).
• ilse The userid ilse is granted all permissions: read, lookup, insert, delete, write, lock, administer (that is, read, write, add, and delete files as well as change the ACL for the directory). For more about protection groups, see Protection_Groups

l (lookup): allows the user to issue the UNIX ls command to list the names of the files and subdirectories in the directory; to examine the ACL for the directory and to access the directory’s subdirectories; and to look at the contents of the directory (i.e., with the UNIX comand ls -l).
i (insert): allows the user to add new files and subdirectories to the directory (either new or copies of files or subdirectories).
d (delete): allows the user to remove files and subdirectories or move them (where the user has insert rights).
a (administer): allows the user to change the ACL for the directory.

• system:administrators – AFS system administrators
• system:authuser – any user authenticated in the SLAC cell (that is, any user who has a SLAC token)
• system:anyuser – all users anywhere in the world, authenticated or not

You can create groups yourself (that is, the group will be owned by you) that are local to SLAC’s cell. You can add or delete individuals to the group as needed with pts commands. After you have created a group, you can place it on a directory’s ACL with any permissions you choose, and these then apply to all members of the group. Creating a group simply allows you to give the same access rights to several people all at once instead of for each person separately. For the same reason, it is also easier to change lots of ACLs later by just changing the group.

The example below shows how to create a group and add members. Use the commands pts adduser and pts removeuser to add and remove a user, and the commands pts delete and pts rename to delete a group and change a group name.

1. Create a group named ilse:doc where ilse is the owner-name and doc is the actual name of the group (but both components constitute the group-name).

2. Verify members of group ilse:doc

3. Get additional information about group ilse:doc

The fs (file server) command is used to check and set the ACL for directories. Use the command fs listacl directory-name to check the current permissions for a directory.

Copying ACLs Between Directories

To copy an ACL from one directory to one or more other directories, use the fs copyacl command. You can copy the ACL from any directory for which you have lookup right and copy it to any directory for which you have administer right.

In the example below, user ilse is in subdirectory telecom and copies the ACL from subdirectory personnel to subdirectory atom-comm.

1. Check the existing ACL on subdirectories personnel and atom-comm:

2. Copy the ACL from subdirectory personnel to subdirectory atom-comm.

3. Check the new ACL on subdirectory atom-comm.

ACLs for Individual Users

For example, to give user winters access to the directory called doc, user ilse would follow these steps:

1. Make a directory named doc

2. Check the existing ACL on directory doc:

3. Add permissions rlidwk (read, lookup, insert, delete, write, and lock) using the shorthand notation write.

4. Check the permissions again.

To make sure that winters was removed:

ilse@odysseus $ fs listacl doc
Access list for doc is
Normal rights:
system:slac rl
system:administrators rlidwka
system:authuser rl
ilse rlidwka

ACLs for User-Created Protection Groups

To give access to a directory to a user-created group, use the same command, fs setacl, as for individuals. The example below illustrates how to give members of group ilse:doc all access rights using the shorthand notation all.

1. Check the existing ACL on directory doc:

2. Give members of group ilse:doc all access rights using the shorthand notation all:

3. Check the permissions again.

ACLs for System-wide Protection Groups

To change the access on a directory for a system-wide protection group, use the command fs setacl. Do not change the permissions for system:administrators. This example shows how to change the permissions of group system:authuser from lookup and read to lookup, read, and insert files for directory doc.

give the command: fs setacl /afs/slac/u/sf/ilse system:slac none system:authuser none

The following shows the revised settings.

• If the r mode bit is present, that is, enabled, anyone with the read and lookup rights on the ACL of the file’s parent directory is allowed to read the file. If the r bit is absent, no one (including the owner) can read the file, no matter what permissions they have on the ACL.
• If the w mode bit is present, anyone with the write and lookup rights on the ACL of the file’s parent directory can modify the file; if the w bit is off, no one can modify the file, not even the owner.
• Although no ACL right directly corresponds to x, if the x bit is on, anyone with read and lookup rights on the ACL of the file’s parent directory can read the file to execute it.

In spite of the above, the UNIX chmod command still turns the file permission bits on and off.

Cron jobs. Submit the cron job (that is, a job in which the user requests UNIX to run a specified command according to a specified schedule) with the trscrontab command rather than the crontab command: trscrontab cron-job-name Give the command man trscrontab for more information.

Interactive jobs. In another command window on the same host enter the tokens command periodically to see whether your token will soon expire. If so, renew it with the klog command.

Mail. If you have a .forward file that executes a program which modifies files in your home directory, send email to unix-admin@slac.stanford.edu for assistance.

File Backup

system:slac gives all users, AFS authenticated or not, of hosts connected to the SLAC network the privilege to issue the UNIX command ls to list the names of the files and subdirectories in your home directory; they may also read the data in the files of your home directory.

system:administrators that is, SCS AFS system administrators, have all access privileges (read, lookup, insert, delete, write, lock, and administer) to the subdirectories and files in your home directory. It is our policy that you not remove the system:administrators entry from any ACLs.

system:authuser gives any user authenticated in the SLAC cell the same privileges as those described for system:slac.

Commands summarized in this appendix are only those used in this Guide. See Introduction to AFS for a complete list of AFS commands and a full description of the command syntax. There you will find an explanation of when keywords in arguments (e.g., -dir) must be specified and when they can be omitted, and when multiple occurrences of arguments (e.g., -user username1 username2 ...) are allowed or prohibited.