--On Friday, June 26, 2009 11:35:32 AM -0400 Jeffrey Altman
<[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
