--On Sunday, June 28, 2009 10:41:46 AM -0400 Jeffrey Altman
<[email protected]> wrote:
What the OpenAFS Windows client does is actually quite smart. It avoids
a large numbers of FetchStatus calls that are unnecessary because the
relevant access right info for the current user is the same on every
item in the directory. If a callback already exists on an object in
the directory from another user, there is no reason to go obtain another
one just to obtain access rights that are already known.
I'm confused. I thought you said the Windows client maintains access cache
information on a per-object basis; now you're saying it shares cached
access rights among all objects in a directory, just as the UNIX client
does. Which is it?
In answer to some other questions/comments in this thread...
No client interprets ACL's to decide what access to grant to which users.
Perhaps more importantly from an interoperability standpoint, it is already
the case that no client _can_ do that -- clients don't have enough
information to interpret ACL entries correctly.
I don't think it's acceptable to restrict access on all files in a
directory to that permitted by the most restrictive file ACL, and as
someone pointed out, doing that would be messy (read: expensive) anyway.
It's also not acceptable to prevent old clients from accessing anything in
a directory containing any per-file ACL's, warning or no. It's also a bad
idea for the fs storeacl command to _sometimes_ fail or become interactive
based on whether there are already any file ACL's in a directory; that's
going to make scripting a nightmare.
Besides being unacceptably restrictive, limiting access based on whether
the client advertises support for per-file ACL's via a capability is also
not secure, since the RXAFSCB_TellMeAboutYourself() call is not secured and
thus its result can trivially be modified by an attacker. Note that the
same is true of the VLF_DFSFILESET flag; many of the older clients we're
talking about do not authenticate VLDB operations.
I think we can do better. In particular, I would like to consider the
possibility of having the fileserver manipulate the UNIX mode bits based on
per-file ACL's, and whether this can be used to mitigate or prevent
information leakage without being overly restrictive. This may be
valuable, as existing clients do interpret the UNIX mode bits on a per-file
basis, and will not allow read access to a file if the u+r bit is not set.
However, these bits are not cached per-user, so it may be necessary to
report the most restrictive value -- if there is anyone who cannot read a
file, then the 'r' bit must be clear.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
