PNCE User Intro to AFS

PNCE User Documentation

Introduction to AFS

The PNCE-Unix environment makes use of the Andrew File System (AFS) for home and group storage. AFS is different from standard Unix file systems (UFS) in a number of ways. Most significant among these is the way in which files are protected in AFS. Unlike UFS, AFS does not use the standard Unix permission bits for much; most access is controlled via access control lists (ACLs). ACLs act at the directory level, and allow access to be tailored to individual users and user-defined groups, unlike UFS. The standard homespace and groupspace directory structures are set up with ACLs designed to allow a reasonable degree of security and flexibility. It is advised that you do not change them unless you know what you are doing. If you are concerned about the security of certain files, please feel free to contact PCS to have them audit the ACLs. For more information about AFS access control lists.

The PNCE-Unix system also uses Kerberos for authentication. This provides additional security over standard Unix authentication procedures. Unlike standard Unix authentication schemes, Kerberos is based on the user obtaining tokens from trusted security servers. These tokens are only valid for about a day, and are necessary for you to prove your authorization to access files. Generally, the process of obtaining and destroying tokens is done automatically for you when you log on and off of the system. However, you may find that if you leave yourself logged in too long, your tokens may expire and need to be renewed. This may be problematic for long running batch jobs---currently we recommend that long running jobs use the scratch disk for all input and output as that is an NFS filesystem (and so uses standard Unix security not Kerberos). Similar problems may occur if you log out after starting a background process that requires authentication, due to the destruction of your tokens when you log out (and unless the background job started a new process authentication group, which is not the default behavior, the destruction of the tokens of your batch job). This can also be avoided by using non-AFS space (eg /scratch), or by using the pagsh command.

Some useful commands

The following commands may prove useful to you:

Commands relating to authentication and tokens

renew:
This will prompt you for your password, and extend the lifetime of your tokens for a day from now.
tokens:
This will list your AFS tokens, and in particular tell you when they expire.
pagsh
This spawns a new shell with a new process authentication group. This is particularly useful for users who wish to start a background job that will not not lose its tokens when the user logs out. For example, if you create the script test_script:

#!/bin/sh /usr/afsws/pagsh << ==EOF== my_batch_job ==EOF==
you can then run test_script & without worrying about problems if you log out before it is done. Logging out after starting my_batch_job could cause problems if it accesses files in AFS space. Note that you may still have problems if the job exceeds the ticket lifetime. Contact PCS if having issues with long running jobs.

Commands relating to disk quotas

fs listquota DIRECTORY or fs lq DIRECTORY
This will show quota and usage for the named directory. The first word in the output line is the volume name; the quota actually acts at the volume level and all files/directories in the same volume share and count against the same quota. You can replace DIRECTORY with a tilde (~) to get your homespace quota.

Commands relating to access control lists

For more information on AFS access control lists

fs listacl DIRECTORY or fs la DIRECTORY
This will list the access rights to a given directory in AFS-land.
fs setacl -dir DIRECTORY -acl USER ACL or fs sa -dir DIRECTORY -acl USER ACL
This will set the access rights to a given directory in AFS-land.
setacl_tree DIRECTORY USER ACL (NOTE: this is not a standard AFS command but a script for UMd Physics users.)
This will set the access rights to a given directory and all of its subdirectories in AFS-land.
make_private_dir and make_private_tree: (NOTE: these are not standard AFS commands but scripts for UMd Physics users.)
These two commands take a directory name (required to be in Physics groupspace), and restrict access to that directory (and in the case of make_private_tree all subdirectories) so that no one else can read the files but you (system staff and authorized group managers can also do so, but even then some safe guards to make accidental reading difficult)
make_group_readable_dir and make_group_readable_tree: (NOTE: these are not standard AFS commands but scripts for UMd Physics users.)
take a directory name (required to be in Physics groupspace), and restrict access to that directory (and in the case of make_group_readable_tree all subdirectories) so that it is readable only by members of your research group. I.e., it restores the default Physics AFS ACLs for a directory in groupspace.
make_public_dir and make_public_tree: (NOTE: these are not standard AFS commands but scripts for UMd Physics users.) take a directory name (required to be in Physics groupspace), and open access to that directory (and in the case of make_group_readable_tree all subdirectories) so that it is readable by anyone logged into an AFS system. I.e., it makes the contents of the directory world readable (assuming that people can get to the parent directory).

For more information

Users who wish to learn more about AFS are referred to the following web sites: