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

[Jeffrey Hutzelman]

--On Friday, June 26, 2009 11:35:32 AM -0400 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

>    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
>       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.

Agree

>    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.  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.  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.

Agree.  Note that users familiar with AFS are likely to mostly use fs 
getacl/setacl on directories anyway, but RXAFS_StoreACL on a file should 
probably fail if the server is file-ACL-aware.

>    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.

Yes, that will be an issue.

>    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.
>    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.

Like it or not, it's what we must do.  Setting this bit is necessary to 
prevent older cache managers from determine file access by looking 
primarily at the user's (presumably cached) access rights on the containing 
directory.  The CM understands that some access is controlled by the UNIX 
u+rw bits on the file and by the AFS 'a' ACL bit on the file, but to get it 
to handle AFS access rights on a per-file basis, the VLF_DFSFILESET flag 
must be set.

There are other behavior changes, but none of these are problematic 
provided the fileserver actually implements the new behavior.  These 
include things like special handling for the two high-order bits of the 
vnode number on a StoreACL call (if we don't implement DFS default ACL's, 
then this just requires the fileserver not permit vnode numbers larger than 
0x3fffffff, which I believe is already the case for namei), special 
handling for FetchData lengths with the high bit set (which requires that 
the fileserver not return negative lengths), etc.


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

Me too.  My guess is that kAFS, like the OpenAFS Windows cache manager, 
does not recognize the VLF_DFSFILESET flag but also does not do the kind of 
axs-cache sharing which the OpenAFS UNIX cache manager avoids only if that 
flag is set.  But it would be useful if David would speak up.

-- Jeff