[AFS3-std] Per-file ACLs - a few items for discussion

[Jeffrey Hutzelman]

--On Saturday, June 27, 2009 12:37:24 PM -0400 Marc Dionne 
<marc.c.dionne@gmail.com> wrote:

>>> - DFS mode might have some subtle behaviour changes, for instance with
>>> implicit permissions based on owner and mode bits, etc.
>>
>> No; the AFS cache manager does not ever do this kind of second-guessing.
>> It depends on the fileserver/translator to tell it what the user's
>> effective rights are on each vnode.
>
> Well there's quite a bit of logic for files in afs_AccessOK()
> (afs_vnop_access.c) that's skipped in DFS mode - I'm assuming there's at
> least some cases where there's an impact there.

Yes, there's a fair bit of logic because the cache manager is caching ACL's 
on a per-directory basis, and other information on a per-file basis.  To 
know whether to grant a user access to a file, it must combine information 
from that user's access rights on the file itself and on the containing 
directory, as well as the UNIX mode bits on the file, which further 
restrict read and write access.  This combining is necessary only on 
non-DFS files, which do not have their own ACL's.  On objects which have 
their own ACL's (directories and all DFS objects), the behavior is simple 
-- just use the AccessRights reported by the server.

Note also that a user never _gains_ access based on mode bits that would 
not have been permitted by the ACL, and that the client does not interpret 
the file owner at all.  It _does_ use what the fileserver says about 
whether the user has 'a' access to the file, but only if the user is 
performing an operation which requires that information -- mostly, 
performing administrative operations on the file such as changing its mode. 
On a directory or DFS object, the 'a' rights are still used in that manner, 
but no contortions are necessary to merge them with the rest of the access 
rights bits, because they already all came from the same place.

-- Jeff