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

[Marc Dionne]

On 06/26/2009 11:35 AM, Jeffrey Altman wrote:
> Marc:
>
> Thanks for writing these issues up for our review.   I need to think
> about the desired behaviors a bit more but I want to add a few items
> into the mix for consideration by the group.

Hi Jeff, thanks for the feedback.

>     1. The existing RXAFS_FetchACL and RXAFS_StoreACL RPCs are specified
>        as accepting only a directory FID.  While it is true that the
>        OpenAFS file server will accept any FID for the RXAFS_FetchACL
>        call and always returns the ACL of the directory, this behavior
>        should not be relied upon.  As part of this work new

Are there documents somewhere that specify the existing protocol with 
that level of detail?  With only implementations as a guide, it's often 
not obvious to distinguish what is protocol and what is an 
implementation choice.
Seems to me that we have to allow the existing FetchACL RPC to refer to 
files, otherwise old clients will have no way to determine the effective 
access rights on a file.

Can we agree at a minimum that for an old client:
- "fs la <file>" should show the effective rights on the file - i.e. 
shows an ACL that accurately predicts the failure/success of operations 
performed by this client
- "fs sa <file>" should either fail (ENOTDIR) as it does now, or set the 
effective ACL on the file.

>        RXAFS_FetchACL2 and RXAFS_StoreACL2 RPCs should be added to
>        support the new functionality.  If the old RPCs are called, the
>        old behavior should be expected.   This permits the new
>        RXAFS_FetchACL2 response to not only return the current ACL that
>        applies to the specified object but also whether or not that ACL
>        is inherited from a parent.  The new RXAFS_StoreACL2 could make
>        available options that permit the client to specify things like
>        "inherit from parent".  The use of new and old RPCs also provide a
>        method for new clients to behavior properly with old servers.

Exactly what's needed in those new RPCs will depend on the inheritance 
model, but yes, having new RPCs would allow for more complex interactions.

>     2. I believe that the inheritance model that we select must be one
>        that is going to reduce the confusion for end users that may be
>        forced to use a mixture of old and new clients.  The old clients
>        will be able to read the current ACL on an object whether it is
>        inherited from the directory or associated specifically with the
>        object.

So you're saying that the existing FetchACL RPC would be allowed to 
specify a file object, and the server would return the _effective_ ACL, 
regardless of whether it's stored as-is or computed at the other end.
Agreed, that's pretty much what my current implementation does.

>        However, the old client is not going to be in a position
>        to alter the value of an ACL that isn't associated with a
>        directory.

Well, if we also consider that the existing StoreACL RPC can specify a 
file object, then an old client could be allowed to modify a file ACL. 
The server would do what's needed on its side (depending on the 
inheritance model) to achieve the requested effective ACL.  This might 
be tricky if the model is more complex.
It's probably acceptable to restrict storing file ACLs to new clients, 
but it would be nice if it worked for old ones as well.

>        There is not going to be a perfect solution but I
>        believe the "inherit until set" model is the one that will work
>        best for users that are only using "old clients".  We may need to
>        have a restriction that old clients while they can see the value
>        of a per-file ACL, they can't change it even though they can
>        change the value of the directory's ACL.

The problem I saw with that model (inherit until set) is that the result 
of a StoreACL on a directory for an old client won't be well defined wrt 
what that client can see.  As a principle I think that even an old 
client should have the means to accurately predict the outcome of a 
StoreACL operation on files in that directory.  I know jhutz touched on 
this in another mail - I'll have a look.
Also, we could allow old clients to set ACLs (see above).

>     3. Regarding hard links from multiple directories.  If we select a
>        "inherit until set" model, we would either need to prevent the
>        creation of such hard links until a per file acl was set or
>        automatically create a per file acl based upon the previously
>        inherited acl.

Agreed, allowing hard links would imply insuring that the permissions 
are the same for both locations, either by denying the operation in some 
cases or adjusting the ACL in the target location so that it matches.

>     4. I hope the issue surrounding FetchStatus permissions is a
>        non-issue.  I'm not as familiar with the behavior of the Unix
>        cache manager but in the Windows cache manager the described
>        behavior is an optimization to prevent issuing FetchStatus
>        requests that can reasonably be determined to fail.  The access
>        rights are maintained per object so there will be no inconsistency
>        if the FetchStatus on two different objects in the same directory
>        provide different access rights.

The issue here is similar to the one with file data (see below).  The 
inconsistency is not that different objects in a directory may have 
different access rights, but rather that FetchStatus will behave 
differently for the SAME object depending on the current cache contents.

>     5. VLF_DFSFILESET is used in the Unix cache manager.  It is not
>        present in the Windows cache manager.  I really do not like the
>        idea that we will need to rely on setting flags in the VLDB in
>        order to permit proper use of per-file acls.  Adding DFS
>        functionality to make it happen also just seems wrong.   Can you
>        explain a bit more about what the behaviors of the Unix cache
>        manager are if this flag is set or not set?  A quick look shows
>        that there are more behavior changes than just access rights.

The problematic behaviour is that the cache manager will allow access to 
cached file data based on the directory permissions.  So a user with no 
rights to a particular file will be able to read its contents if another 
user on the same system has already read it and brought it into the 
cache.  This violates the file ACL, and makes the result vary depending 
on cache contents.  The DFS flag may be the only hook we have to adjust 
this for existing clients.

I haven't tested with the Windows client yet (I will do so), but with a 
quick look at the code I suspect we'll have the same issue, with perhaps 
no workaround - it's clear that the DFSFILESET bit won't help us there. 
  That's a problem.

>     6. I would like to know what kAFS and Arla do.

Yes it would be good to do testing with them as well.  I don't have them 
setup currently, but I have experimented with kAFS in the past.

Marc