Locker ownership check should include magic admin bit

[Geoffrey Thomas]

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.)

[Anders Kaseorg (andersk)]

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.)