AFS Guided Tour
Most likely, your home directory is located in the Andrew File System, AFS. This tour will give some information on how to use AFS.
Differences between AFS and Unix File System (UFS)
The following describes the main differences between AFS and UFS.
- File access differs
The access right to a file is controlled by so called Access Control Lists, ACL. These lists controls your rights in a directory. Each directory has a ACL, describing what you (or anyone else) can do in that directory. Subdirectories inherits the ACL of the parent directory when created. More about this in "Access Control List"
- The command ls doesn't show file protection
Only the three first of the nine file protection codes you see
when you type ls -al is used by AFS. These would normally
describe the owners rights to these files, but shows in AFS if the
file is read- write- or executable for all those who have access to
- Problems with your home directory
Since the the access to a file is based on directories rather than files, you might have problems with directories that should contain both public and private files. This is typical for your home directory, certain init files must be public readable, but you don't want all your files in your home directory to be public readable. A solution to this is presented in Protecting your init files.
- You need Kerberos tickets
To access your AFS-files you need a valid ticket in the authentication system Kerberos. Normally you get these automatically, but sometimes you must obtain a ticket manually. One such case might be when you login to a remote system with rsh, rlogin, telnet or xtelnet. You can not move a ticket between the computers so, you must get a new ticket by using the command kauth. A ticket is by default valid for 25 hours but its lifetime can be extended, see the Kerberos Guided Tour for details.
- Quota for your disk space
Each AFS-directory has a limit for the space it may use on discs. The command fs listquota or fs lq for short will show the disc quota in the current directory. The default quota at PDC is 500 MB. Contact PDC if you need more disc space.
- AFS is global
Anybody anywhere in the world using AFS can access your files, given that they have the proper access rights. This has some advantages: you can access your files without logging in to a PDC computer, but has also some risks: if you're not aware of this you might make your files readable for anyone. You should read the section on Access List Control thoroughly.
Access List Control, ACL
Every directory in AFS is controlled by a list describing different users rights in that directory. To see the the list you use the command fs listacl or shorter fs la. This command entered by the user svensson might result in something like this:
> fs la
Access list for . is
Before going in to detail what the list describes we should take a look at what you can do to a directory. Each action you can perform in a directory has its own letter:
r read Read the files in the directory
l list List the files in the directory
i insert Create new files
d delete Delete files
w write Modify files
k lock Lock files in the directory
a administer Change the ACL for the directory
In the example earlier we see that the user svensson has all the rights to his directory, so does the group system:administrators. The group system:anyuser which contains all the users of AFS in the whole world may read and list the files in this directory. Finally svensson's friend andersson has all the rights except the right to change the ACL.
To alter the ACL you use
> fs setacl [directory] user rights
You may shorten setacl to sa. Assuming that you are in your home directory and that you want to give the user mysister some rights in this directory you could write
> fs sa . mysister rliw
This would make it possible for mysister to read, list, create new files, and to modify existing files.
By default fs setacl adds to or alters the contents of the ACL instead of replacing it. To revoke the rights given to a user you must use the the following command:
> fs sa [directory] user none
To see all the available commands with fs use fs help.
Protecting your init files
Since the file protection is on the directory rather than file level you cannot not have different levels of rights on the files in directory. Normally, this is not a problem, you just put the files you want to keep secret in a directory (often called Private) and public files in another directory (called Public). However this may pose a problem in your home directory which contains files that should be public readable such as .login, .forward, .tcshrc and others. If these files are not public readable, programs like rlogin will not function properly. You have also files that you don't want other to read, like the file mbox where your email is stored.
The trick to solve this is to make a public readable subdirectory containing the files. In your home directory you then create symbolic links to these files. The links will allow you to read the files which now appear as public readable. You should not make your home directory public readable.
One example to clarify the method;
Change to your home directory:
Create a subdirectory:
> mkdir Public
Make this subdirectory readable by any user:
> fs setacl Public system:anyuser read
Move all the files that should be public readable to this directory:
> mv .login .cshrc .tcshrc .forward Public
Create the links:
> ln -s Public/.login .
> ln -s Public/.cshrc .
and so on...
Every user in the AFS-system can create groups of users. All the members can then be given the same access rights by adding the group to an ACL. This is a very convenient way of giving the same rights to a group.
In the ACL you recognise groups by that they are in a format owner:groupname, in the example earlier in this document we see the group system:anyuser. This is one of the systemsgroups of which the most important are:
- system:anyuser This is all the users of AFS all over the world.
- system:authuser This is all the local users of AFS.
- system:administrators This is the group of systems administrators, they have all the rights to all your directories, regardless what you define in your ACL.
To create your own groups you use the command pts:
> pts creategroup owner:groupname
Creates a new group, owner should be your username. You can shorten creategroup to cg
> pts adduser user owner:groupname
Adds a user to a group. We can shorten adduser to ad.
> pts delete owner:groupname
Deletes a group, short for delete is del.
> pts removeuser user owner:groupname
Removes one user from the group, there is a shorter version of removeuser which is rem.
> pts membership owner:groupname
Lists the members in a group, the short for membership is m.
> pts help
Will give you a list of all the commands to pts.
Here is an example, assume that you have two friends svensson and andersson. You want to give them certain rights in a directory called my_secrets. Yor own username is me. First in your home directory, you create the group friends:
> pts creategroup me:friends
Then you should add the users to the group
> pts adduser svensson me:friends
> pts adduser andersson me:friends
All we have to do now is to add this group to the ACL for the directory my_secrets. Assuming that my_secrets are a subdirectory under your home directory you would type:
> fs setacl my_secrets me:friends rlidw
which would let members of the group friends read, list, insert, delete and write files in your directory. You use fs setacl in the same way for users and groups, just remember that a group is written as owner:groupname.
Accessing other cells
If you want to access files that are located somewhere else, e.g. your
home directory at another institution that uses AFS, you need to
acquire tokens for that cell (unless the files you want are readable
by anyone, in which case you don't have to do anything special). This
is done by first getting kerberos tickets for the corresponding realm
and then getting tokens from those tickets using the command afslog.
As an example, assume that you have an account user@PHYSTO.SE with the
home directory /afs/physto.se/home/u/user. First you need to get
> kauth user@PHYSTO.SE
Then you need to acquire tokens:
> afslog -c physto.se
You should now be able to read and write the files in
back to guided tours