Contents


Abstract

When working with a group of people on a project of any magnitude, there has to be a sharing of data between members. Email is good for inter-group communications and FTP is fine for working on files from home and transferring them back to your school account, but neither are suitable for sharing files between group members.

The solution to this is to create a common directory for files that all of your group members can access without fear that other people will be able to access them as well. This can easily be done using the AFS filesystem. The AFS (Andrew File System) is the file system used on the GPU servers and the CEB 531 Cad lab, both of which are accessible using your CNS computing ID.


AFS and Permissions

As you may know, each file in Unix has it's own set of permissions that can be viewed by using the ls -l command. The permissions consist of three sets of three bit numbers, which determine whether read, write, and/or execute permissions are granted for the file. The three sets of permissions determine the access rights for three different groups: the owner of the file, the group the file belongs to, and all other users of the system.

However, on an AFS system, these permissions are superseded with the filesystem's own set. Under AFS, permissions are given for an entire directory and its contents by defining an Access Control List (ACL) for that directory. Furthermore, subdirectories inherit the ACL of their parent directory unless that subdirectory explicitly has an ACL defined for it. Finally, each user can define multiple groups, add other users to these groups, and specify the permissions for each group in an ACL.

The following is a list of the permissions that can be applied to a directory:

r (read)
- This right allows the possessor to both list and read the files in the directory
l (lookup)
- This right allows the possessor to list the files in the directory using the ls and associated UNIX commands
i (insert)
- This right allows the possessor to add/copy/move new files and subdirectories to the directory
d (delete)
- This right allows the possessor to remove files and subdirectories
w (write)
- This right allows the possessor to modify the files in the directory and to change the UNIX protection bits of individual files using chmod
k (lock)
- This right allows the possessor to run programs in the directory that require file-locking
a (administer)
- This right allows the possessor to change the ACL of the directory

As a convenient option, the separate access control rights shown above can also be grouped together to form four different packages of access control rights. These four packages are:

write
- This rights package gives the possessor read, lookup, insert, delete, write, and lock rights (i.e., rlidwk)
read
- This rights package gives the possessor read and lookup rights (i.e., rl) to an AFS directory
all
- This package of rights gives the possessor read, lookup, insert, delete, write, lock, and administer rights (i.e., rlidwka)
none
- This option removes from the possessor all previously granted access control rights to an AFS directory

Creating a Group

There are several predefined groups: system:administrators, system:authuser, and system:anyuser. By setting permissions for these groups, you can allow large numbers of users to access your files. For example, when creating a web-accessible directory on GPU, you give the system:anyuser group read and lookup permissions to your home directory, so that web browsers are able to locate your html files. In addition, groups can be created by any authorized user of the system. Basically, this means you. To create a group, the command syntax is pts creategroup <youruid>:<groupname>. For example:

gargus@cadxx: pts creategroup gargus:mygroup

This creates a group under your userid named youruid:groupname. In the example above, the group is named gargus:mygroup. Note that the group created has no users added to it; it is empty. Man pages for the pts command should available on the system. Also, typing pts help will list all of the pts commands with a brief explanation of what they do.


Adding and Removing Group Members

First, create a group as described in the Creating a Group section. In order to add a user to the group, use the following command: pts adduser <newuser> <youruid>:<groupname>. This will add newuser to the group youruid:groupname. In order to add multiple users to your group, simply repeat the command above for each user, or use the following slightly modified syntax: pts adduser -user <newuser1> <newuser2> <newuser3> -group <youruid>:<groupname>. An example using all of these commands is as follows:

gargus@cadxx: pts adduser psomogyi gargus:mygroup
- adds psomogyi to the group gargus:mygroup
gargus@cadxx: pts adduser -user khackett scaplan -group gargus:mygroup
- adds both the users khackett and scaplan to the group

In order to confirm who is in your group, use the command pts membership <youruid>:<groupname>. Continuing in the example above:

gargus@cadxx: pts membership gargus:mygroup
khackett
psomogyi
scaplan

The syntax for removing a user from a group is the same as for adding, save that you substitute the string "adduser"; with the string "removeuser".


Changing Directory Permissions

It is quite easy to share directories under AFS using Access Control Lists. The important thing to note is that the ACL specified for a parent directory will automatically apply for all child directories unless they have an ACL defined on them, which will take precedence. It is possible to change the ACL for one user with the following command: fs setacl <dirname> <uid> <permissions>, where the permissions are chosen from the set listed in AFS and Permissions. For example, to give the specified userid read and lookup access to a directory, the command would be as follows:

gargus@cadxx: fs setacl shared_directory khackett rl
OR
gargus@cadxx: fs setacl shared_directory khackett read

Note that the two are equivalent, since the the permissions group "read" is equivalent to the permissions "rl". However, it is a lot easier to create a group, add users to the group, and then set the ACL for the group as a whole. The syntax for doing this is only slightly different: fs setacl <dirname> <uid>:<groupname> <permissions>. Thus, continuing the above example and using the group created in the previous section, the commands would be as follows:

gargus@cadxx: fs setacl shared_directory gargus:mygroup rl
OR
gargus@cadxx: fs setacl shared_directory gargus:mygroup read

In order to view the permissions on a directory, use the command fs listacl <dirname>. Another useful command that uses the file system fs command, but is not really related to permissions, is fs listquota <dirname>, which will indicate how much of your disk quota that particular directory is taking up. Using "~" (your home directory) as your dirname will thus list your total quota usage. Finally, it is useful to note that "setacl" can be abbreviated as "sa", "listacl" can be abbreviated as "la", and "listquota" can be abbreviated as "lq".


Practical Example: Sharing your VHDL Code

This example provides precise step-by-step instructions and command to create a directory, create an AFS group, add your group members to it, and grant them access to the directory. The instructions are given without explaination; the reader can refer to the above text for a more complete discussion. The aim of this is to show how to create a common repository for your VHDL code that can be shared between all of the members of your group, thus allowing it to be easily placed under version control. (Note: App note on version control is currently being developed).

  1. Decide which member of your project group will host the directory. This will probably be the person with the most free space. Use fs lq ~ for each user to find out who this is. All of the following commands should be performed by that user.
  2. Create a directory for the shared VHDL code. The command mkdir code will accomplish this nicely.
  3. Create an AFS group for your group members. The command pts creategroup youruid:vhdl will do this. Of course, replace the string "youruid" in that command with your actual userid.
  4. Add the other group members to your group with pts adduser -user uid1 uid2 uid3 -group youruid:vhdl. Again, make the obvious substituitions.
  5. Give your group access to your code directory. The command fs setacl code youruid:group write will give them sufficient permissions.
  6. Give your group lookup access to all directories above your code directory. Assuming you have no other permissions defined for this group (which you won't if you followed these instructions), it suffices to use the command fs setacl ~ youruid:vhdl l. Your group will require lookup access in order to be able to change directories to your code directory. Note that they will not be able to read any of your other files.
  7. You are now done. It may take some time for AFS to propagate this group to the other users, or they may have to log in again in order to be able to access your shared directory. I'm not quite sure on this point, and would appreciate corrections.

Other Resources

An Introduction to the Andrew File System
Computing and Network Services: Using the Andrew File System


Feedback

Please feel free to submit comments, questions, and feedback in general on this topic to the address shown at the bottom of the page. I will answer your questions and update this document to improve its overall clarity and utility.


Maintainer: Javan Gargus, <javan@cs.ualberta.ca>
Last Update: 10:07pm on Monday, Oct 5, 1998