Opened 11 years ago

Last modified 10 years ago

#165 new enhancement

Locker ownership check should include magic admin bit

Reported by: geofft Owned by:
Priority: normal Milestone:
Component: internals Keywords:
Cc:

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 them unable to log in 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.)

Change History (2)

comment:1 Changed 11 years ago by andersk

See also XVM bug 633614.

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

comment:2 Changed 10 years ago by ezyang

  • Type changed from defect to enhancement
Note: See TracTickets for help on using tickets.