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.
The following commands may prove useful to you:
/usr/afsws/pagsh << ==EOF==
test_script &without worrying about problems if you log out before it is done. Logging out after starting
my_batch_jobcould 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.
fs listquota DIRECTORYor
fs lq DIRECTORY
DIRECTORYwith a tilde (~) to get your homespace quota.
For more information on AFS access control lists
fs listacl DIRECTORYor
fs la DIRECTORY
fs setacl -dir DIRECTORY -acl USER ACLor
fs sa -dir DIRECTORY -acl USER ACL
setacl_tree DIRECTORY USER ACL(NOTE: this is not a standard AFS command but a script for UMd Physics users.)
make_private_tree: (NOTE: these are not standard AFS commands but scripts for UMd Physics users.)
make_private_treeall 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_tree: (NOTE: these are not standard AFS commands but scripts for UMd Physics users.)
make_group_readable_treeall 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_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_treeall 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).
Users who wish to learn more about AFS are referred to the following web sites: