AFS Info | F.A.Q. | Basic AFS | Advanced AFS | Kerberos | Features | Other Info
Under AFS, permissions are set by directory not by file. Every file in a directory has the same permission. New directories inherit the parent's permissions.A directory's permissions is contained in the Access Control List (ACL). An ACL may have up to twenty entries. There are seven permissions you can set:
NOTE: read, write, lock, insert, delete, and administer permissions all require lookup permission. The filing system cannot tell what file permissions the user has without lookup privilege. Similarly, users cannot access a subdirectory unless they have lookup privileges for ALL its parent directories.
The command fs is used to examine and change the ACL. It has a whole suite of subcommands; the major ones are fs listacl, fs setacl, and fs listquota.
Example:
Listing an acl:
elaine:~% fs listacl ~consult
Access list for /afs/ir/users/c/consult is
Normal rights:
system:administrators rlidwka
system:anyuser rl
consult rlidwka
Example:
Give read and lookup privileges to any user for your
home directory:
fs setacl ~ system:anyuser rl
Remove privileges for your private directory:
fs setacl private system:anyuser none
Giving user frank lookup, read, insert, and write
privileges to the directory project:
fs setacl project frank lriw
Warning: becareful who you give write permissions to. AFS users have limited quotas of 6mb, if you give write permissions a lot of people, you may find yourself running out of disk space.
To list your disk quota, type:
fs listquota
To list other user's quota, type
fs listquota ~[username]
Okay, now that you have the basics down, here are some
abbreviations to make your life slightly easier:
| fs setacl | is | fs sa |
| fs listacl | is | fs la |
| fs listquota | is | fs lq |
There are shortcuts for the ACL permissions
| read | rl |
| write | rlidwk |
| all | rlidwka |
| none | (none -- removes user from acl) |
Between midnight and 3 AM each night, a backup image of
your account is made. If you delete or modify a file in an
AFS volume, you may be able to retrieve the file if it existed
when the backup image was made. NOTE: Under most
circumstances, you should be able to just go into your .backup
directory and copy what ever file from there directly with out
going through the following steps. However, sometimes the
volume containing the backup is not mounted, so you may have
to employ the following steps. The command:
fs mkmount ~/.backup user.$USER.backup
will mount your backup volume in the directory named .backup
in your home directory. You can use a name other ~/.backup if
you want. To unmount the volume type:
fs rmmount ~/.backup
You don't need to unmount it: files in .backup do not count against your disk quota usage.
The backup volume (user.$USER.backup) is a read-only copy of your account. You cannot remove or alter files in the backup volume, and file changes made after the last backup but before the next backup are not available. To restore a file, you must copy the file from the backup volume to your account.
Suppose you delete the file ~/Mail/incoming. The following
commands may recover it (assuming you have sufficient quota
and you do it in time):
cd
fs mkmount ~/.backup user.$USER.backup
cp ~/.backup/Mail/incoming ~/Mail/incoming.bak
fs rmmount ~/.backup
The recovered file would be named incoming.bak in the Mail
directory.
Many AFS commands can be executed with a help argument or flag.
To get a list of the fs subcommands, type:
fs help
To get a somewhat cryptic syntax list for a subcommand, you
can type:
fs [subcommand] -help
To get the rather worthless manual page, type:
man fs
If it doesn't mention AFS, then add the following line to
your .login:
setenv MANPATH
'/usr/man:/usr/local/man:/usr/pubsw/man:/usr/pubsw/X/man'
That should give you a reasonable man page path.
When you login to your account, you obtain a "token" that is your validation to the local computer that you are who you say you are. This token has a lifetime of 24 hours. If your token expires, you are considered to be system:anyuser and will lose access to your private directories.
To check if you have a token, run the command tokens.
To obtain a new token, run klog. This will prompt you for your password and obtain a new token for you. If your username and AFS username are different, then use klog -x [afsusername], where [afsusername] is your AFS username.
If you have trouble finding these commands, they should be located in the directory /usr/pubsw/bin.
For more information about tokens, read the kerberos section.
The default account setup has list privileges for system:anyuser on all your directories except the private and Mail directories.
The rest of section 3 outlines how to setup your dotfiles (.rhosts, .plan, .project, .forward), create public directories, and increase both account security and openness. A more secure (but more complex) directory setup is outlined in the advanced section. It describes a setup that keeps all the files in your home directory private, but enables you to have public and project directories. The average user should find the information below sufficient, though.
A public directory is the most secure way to store
your .plan, .project, .klogin, and other files that need to be
--or you wish to be--world-readable:
cd
mkdir public
This directory may already exist
fs setacl public system:anyuser read
The cd command takes you to your root directory. The mkdir creates a public subdirectory. The fs command gives read permission to the subdirectory.
Now you can make files public. For example, to make your
.plan file readable, you type:
cd
mv .plan public/
ln -s public/.plan
The mv moves your .plan file to the now world-readable subdirectory. The ln creates a "symbolic link" from the file public/.forward to your root directory.
You can do the same for your .project, and .klogin files,
if you have them.
NOTE: the .forward and .rhosts files do not work on the
leland system; you have to use lelandforward to forward mail,
and a .klogin file to allow
kerberized rlogin or rsh from one Leland host to
another.
For example,
cd ~$USER/
mv .plan .project .cshrc .login .rhosts .dotfiles/
ln -s public/.plan
ln -s public/.project
ln -s public/.klogin
One of the powers of AFS is its file permissions (see section 1.1 for an overview). You can grant permissions to individual users or groups. Since AFS permissions are by directory, you only need to setup the permissions on the directory and its existing subdirectories. Files inherit the permissions of their directory. New subdirectories inherit their parent directory permissions.
In order for a user to access a subdirectory, at least list (l) permission MUST be given on every parent directory of the subdirectory.
If you use the home directory setup described in advanced section, then these directories must be created in ~$USER, not your home directory. You can then make a symbolic link from your home directory to the new directory.
You may already have a public directory in your
account. In case you don't here are some examples
commands that will create one for you:
cd
mkdir public
fs sa pub system:anyuser read
The cd command moves you to your root directory. The mkdir command creates a directory named pub. The fs command makes the directory readable for any user.
Any subdirectories that you create in pub will also be public (since newly-created subdirectories inherit the permission of their parent directory). If you move a directory into this directory or use a symbolic link, however, you may need to adjust the permissions.
Directories which provide insert privileges for anyone are a security hole. Anything added to this directory applies to your quota, so you need to watch the directory.
If you do setup such a directory, it needs a minimum of system:anyuser li. It should have at a maximum system:anyuser rliw.
If you use a subdirectory that someone added to your insert directory, be sure to change the file permissions back to system:anyuser none and to what it should be (public directories should have system:anyuser read).
Suppose you are working a project with curley and
moe. Here's some commands that will create a project
directory:
cd ~$USER
mkdir stooge
fs sa stooge curley write
fs sa stooge moe write
The cd command moves you to your root directory. The
mkdir command creates a project directory named stooge.
The fs commands give users curley and moe write to that
directory. (Be sure that you do not go over quota!) If
you want others to be able to read the files, you can
use:
fs sa stooge system:anyuser read
If you do not want them to have any access, use
fs sa stooge system:anyuser none
For a final example, suppose you are going to be creating five subdirectories: public, private, moe, curley, and larry. Since the names should be obvious, here's how to set them up:
And on moe:
mkdir curely
fs sa curley moe none
And on both of them:
mkdir larry
fs sa larry moe none curley none
And finally, let us strip
system:anyuser from these directories
fs sa -dir larry curley moe -acl
system:anyuser none
To AFS Main Page
