Locker ownership check should include magic admin bit

Bug #633614 reported by Geoffrey Thomas
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

It is the case that the UNIX user owner of the top-level directory in an AFS volume has implicit 'a' access to the entire volume, regardless of permissions as reported by 'fs la'. It's also the case that this owner is visible to all users by statting that directory, whether or not they have 'l' on the volume and can run 'fs la' on it, for instance:

starnine@dr-wily:~$ fs la
Access list for . is
Normal rights:
  system:expunge ld
  starnine rlidwka
opus:~ geofft$ fs la /mit/starnine/
fs: You don't have the required access rights on '/mit/starnine/'
opus:~ geofft$ ls -ld /mit/starnine/
drwxr-xr-x 55 starnine root 6144 2010-08-30 21:17 /mit/starnine/

The authz check for whether someone is an owner of an AFS volume/locker should include checking the UNIX owner of the volume's top-level directory in addition to 'fs la', so that in cases where users (accidentally or intentionally) don't give system:anyuser l permissions on the directory, we can still check that they're authorized for their own locker, instead of making their VMs inaccessible to them because we can't run 'fs la'.

(I just tested, and this does not apply to the UNIX group owner, in case you were curious. So this doesn't help all that much on group lockers.)

Revision history for this message
Anders Kaseorg (andersk) wrote :

If this is implemented, be careful not to apply this check to lockers that are not the root of their volume. (For example, /mit/glab -> /afs/athena.mit.edu/course/15/15.389/www/glab is owned by someone who no longer has an account.)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.