Answers to selected questions.

Febuary 13, 1996

There were a few questions during the AFS talk that I did not answer well. I'll attempt to give a better answers here.

Creating and using PTS groups.

Under AFS it is possible for users to create PTS groups to control access to their directories. This is done with the pts command.

For example:

# pts creategroup sofkam:cohorts
group sofkam:cohorts has id -1997

Creates a new PTS group named ``sofkam:cohorts '' which is owned by user sofkam . Members can be added to the group by the owner:

# pts adduser -user coleman hudsod finkej -group sofkam:cohorts
# pts members sofkam:cohorts
Members of sofkam:cohorts (id: -1997) are:
  finkej
  hudsod
  coleman

This PTS group can now be placed on an ACL to give access (or deny access) to the members of sofkam:cohorts . To give somebody else access to all of the directories with sofkam:cohorts on the ACL just add them to the group. Likewise, to remove access remove them from the group:

# pts removeuser finkej sofkam:cohorts
# pts members sofkam:cohorts
Members of sofkam:cohorts (id: -1997) are:
  hudsod
  coleman

Groups can also be owned by other groups. This allows members of the group to add and remove other members. For example, dept.acm is self owned, so the members of dept.acm can add and remove other members.

For the individual AFS user, the same effect can be achieved by changing the SOMAR bits.

# pts exam sofkam:cohorts Name: sofkam:cohorts, id: -1999, owner: sofkam, creator: sofkam, membership: 0, flags: S-M--, group quota: 0.

# pts setfields sofkam:cohorts -access S-Mar # pts exam sofkam:cohorts Name: sofkam:cohorts, id: -1999, owner: sofkam, creator: sofkam, membership: 0, flags: S-Mar, group quota: 0.

Note, that by changing the SOMAR bits from S-M-- to S-Mar , I've given add and remove access to members of group sofkam:cohorts . Prior to that, add and remove were restricted to the owner of sofkam:cohorts .

Groups can be deleted with:

# pts delete sofkam:cohorts
# pts exam sofkam:cohorts
pts: User or group doesn't exist so couldn't look up id for sofkam:cohorts

Why didn't AFS use all of the UNIX mode bits?

Good question. The short answer is the semantics of interacting ACLs and UNIX mode bits is ugly. The developers of AFS kept it simple by usign ACLs on directories and using the UNIX owner bits to modify specific file access.

For example, in AFS, you can have a writable directory, with specific files marked as not writable by turning off the ``owner'' mode bits. I put ``owner'' in quotes, because under AFS the ``owner'' bits apply to all users, and not just the file owner.

In DFS, the ACLs can be applied right to the file level (at the cost of more client/server/database transactions). And, the ACL permissions are closer to the UNIX permissions (i.e., read, write, execute, control (that is, modify an ACL), insert and delete). Therefore, in DFS UNIX mode bits are not needed.

Despite the lack of need, however, the OSF has decided for the sake of POSIX compatability that UNIX mode bits must be used in DFS. Here is how it works.

DFS ACLs have:

user_obj : The principle who owns the object (fileset, directory, or file).
group_obj : The group that owns the object.
other_obj : Any other authenticated principle from the cell.

In addition, there can be ACL entries for specific users and groups (and, users and groups from foreign cells).

DFS ACLs also have the mask_obj that keeps DFS ACL and UNIX mode bits synchronized. This is to provide ``backwards compatability for programs (and users) that modify UNIX mode bits rather then ACLs.'' It is automatically added and removed from an ACL as needed when ``non-object'' types are added or modified. It cannot be removed.

The mapping between DFS objects and UNIX bits are:

First 3 bit, rwx maps to user_obj ,
Last 3 bits, rwx maps to other_obj ,
Middle 3 bits, rwx maps to mask_obj , or group_obj .

When there is no mask_obj on an ACL, the group_obj maps directly to the group mode bits. When there is a mask_obj the mask_obj maps directly to group mode bits. Fortunately, the edit_acl command shows the effective access according to mask_obj .

The recommendation is to use only ACLs, and never chmod (or, if you do use chmod , never edit the ACLs). If the two are combined (or the original ACL contains non-object types) chmod can remove effective access for more users then intended. Likewise, modifying the mask_obj directly can unintentionally grant access that was not intended. When this happens, edit_acl program issues a warnings. (This is useful if you know what is going on, but if you knew what was going on you would not be editing the mask_obj .)

How do you remove negative ACLs.

First, ACLs and negative ACLs are two separate lists attached to an AFS directory. That is, the negative ACLs do not mask the normal ACLs. For example:

# fs la foo
Access list for foo is
Normal rights:
  sofkam rlidwka
  system:authuser rl
Negative rights:
  coleman rlidwka

coleman , as a member of system:authuser would have access to the directory foo , but the negative ACL removes this permission.

# fs sa foo coleman read
# fs la foo
Access list for foo is
Normal rights:
  sofkam rlidwka
  system:authuser rl
  coleman rl
Negative rights:
  coleman rlidwka

coleman still has no access to foo . The Positive ACL gives him access, which is then removed by the negative ACL. To give coleman access, you must remove the negative access using:

# fs sa foo coleman none -negative
# fs la foo
Access list for foo is
Normal rights:
  sofkam rlidwka
  system:authuser rl
  coleman rl

Now coleman has read access to the directory.

Likewise, setting negative ACLs is not the way to remove an ACL. To remove an ACL, use the none access keyword:

# fs sa foo system:authuser none
# fs la foo
  sofkam rlidwka
  coleman rl

Note, if you had tried:

fs sa foo system:authuser all -negative

you would have removed access for all authenticated cell members.

Negative access and klog.

If I'm give negative access to a directory which is also system:anyuser rl , I can unlog and read the directory (no surprises there). Then, if I klog I can still read the directory. Why?

Very good question. I was able to replicate this effect with no problem. The lesson is, do not put positive access to system:anyuser on directories you do not want accessed.

The reason you can still access the file is that it is in the work stations local cache, so the fileserver is never consulted for another copy. You can demonstrate this by using the fs flush command to flush the illicitly viewed file from client cache. In fact, if another person on the client has accessed the file recently (so it is still in the cache) you can read it without unlog -ing.

This is an example of the one-person-per-workstation assumption underlying AFS. There are other such assumptions. For example, the path used to enter a mounted volume is changed by the latest user on the client to enter the volume. If a volume is mounted multiple times, each person on a client entering that volume will change the latest path. This is why symbolic links are used instead of multiple mounts.

If you have other questions send them to sofkam@rpi.edu. And, thank you to the ACM for inviting me to speak.