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

[Jeffrey Hutzelman]

--On Sunday, June 28, 2009 10:41:46 AM -0400 Jeffrey Altman 
<jaltman@secure-endpoints.com> 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