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

[Jeffrey Altman]

Marc Dionne wrote:
> On 06/27/2009 12:15 PM, Jeffrey Altman wrote:
>> So yes, we have a problem.   Using VFL_DFSFILESET is not going to
>> provide a method of updating existing clients.  The behavior for a large
>> number of existing clients is going to be that the directory ACL takes
>> precedence regardless of what per-file ACLs are set.  As a result there
>> is (as you describe) an information leakage problem.  We do not have to
>> worry about writes because those will be enforced by the file server.
>> Its just reads on cached objects which have a more restrictive policy
>> than that of the directory.
>>
>> I see two possible options when the client does not offer the "I support
>> per-file ACLS capability":
>>
>>     1. if per-file ACLs are set on objects within a directory, the ACL
>>        reported by the old RPCs becomes the most restrictive ACL (which
>>        is going to be messy)
>>     2. if per-file ACLs are set on object within a directory, the ACL
>>        reported by the old RPCs is empty thereby preventing access from
>>        clients that would leak the data.
>>
>> Any other ideas?
>>
>> Jeffrey Altman
>
> First off I believe that clients determine the access rights based on
> the CallerAccess and AnonymousAccess fields in the FetchStatus
> structure, not on the actual ACL returned from FetchACL.  So this type
> of change would affect all RPCs that return a FetchStatus structure,
> not just the new ACL RPCs.  The file server would have to rely on more
> than the use of the new RPCs (ex: client capabilities) to determine
> how to evaluate the access rights.
That is what I intended to mean.   The effective access rights reported
on the directory object would be set to the more restrictive value if
even a single object in the directory has a non-inherited ACL and the
client does not advertise the "I support per-file ACLs capability.
>
> These adjusted rights would also have to be enforced by other calls
> such as FetchData - but I think this relies on the same bits of code
> anyway.
>
> 1. means that granting additional access to a file (wrt the parent
> directory) through a file ACL would not work for old clients.  That
> may be acceptable, but it depends on what people intend to do with the
> new facility.  Of course if it's an issue they have the option to
> upgrade the clients.
We will have to determine if this is even feasible to maintain.   ACLs
do not change all that often but if there are thousands of objects in
the directory with different ACL combinations it is going to be really
hard to figure out what the restricted subset is supposed to be.
> 2. seems too restrictive - setting any ACL on a file would make it
> unusable by old clients.
But easy to implement.
> Both of these mean a user we can have different rights to a file
> depending on the client used - not great, but better than the cache
> leakage scenario.
Agreed.

Jeffrey Altman