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

[Marc Dionne]

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.

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.
2. seems too restrictive - setting any ACL on a file would make it 
unusable by old clients.

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.

Marc