[AFS3-std] Per-file ACLs - a few items for discussion
Jeffrey Altman
jaltman@secure-endpoints.com
Fri, 26 Jun 2009 11:35:32 -0400
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.
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.
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.
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.
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.
6. I would like to know what kAFS and Arla do.
Thanks.
Jeffrey Altman
Marc Dionne wrote:
> Hi all,
>
> I'm currently preparing an RFC style document that details proposed
> protocol and behaviour changes that will go along with the
> implementation of per-file ACLs in the file server. It's been a good
> exercise that has brought up a few questions that deserve some
> discussion.
>
> Much of what is discussed here has been implemented and experimented
> to some extent, but the finer details will wait until further feedback
> and consensus from the community.
>
> I would appreciate some comments on the following points to help
> narrow down some details for a first draft of the proposal. The focus
> should be on the protocol and semantics, not on the implementation
> details (on-disk format, etc.) which should be discussed elsewhere.
>
> 1. Inheritance model
> The question is what inheritance model, if any, should be used. The
> possibilities are somewhat limited if we want to keep things workable
> for legacy clients and stay within the existing command set (fs sa, fs
> la) and RPCs. This is probably one of the most important points to
> clarify. What behaviour would you intuitively expect?
>
> I see some possibilities (I'm sure there could be many more variations):
>
> A. Inheritance only at file creation. Once a file is created, its ACL
> is completely independent from the parent directory - it is not
> affected by a subsequent StoreACL on the parent. This is the simplest
> model and is what is part of my current implementation.
> B. Inherit until an ACL is set. Until an ACL is specifically set on a
> file, the effective ACL is that of the parent. A StoreACL on the
> parent changes the effective file ACL only for files with no specific
> ACL. A problem with this approach is that a client cannot determine
> if an ACL has been previously set on a file, and can therefore not
> predict the result of a StoreACL operation on a directory.
> C. StoreACL on a directory replaces all file ACLs with the specified
> complete ACL. Simple, but not practical if you have an existing
> directory to change with many adjusted ACLs
> underneath.
> D. StoreACL on a directory replaces file ACLs with a merge of the
> specified ACL with any existing file ACL. Better than C, but could
> still be not very practical in some cases. "merge" would have to be
> well defined.
> E. Other...?
>
> The expected behaviour for file moves between directories should also
> be defined.
>
> Note that DFS had the notion of separate default directory ACL and
> default file ACL attached to directories, and there is some provision
> for this in the OpenAFS "fs" code (-id, -if options). But the code
> does not look usable as-is, and this would be a much more complex
> direction to take, both code-wise and for users.
>
> 2. Hard links
> Now that an ACL can follow a file across directories, is there any
> reason that cross-directory hard links should not be allowed, with the
> restriction that the link and target be within the same volume? It
> would require an inheritance model like A. above where the file ACL is
> independent of the directory. This has not been implemented or tested
> yet, but it looks like a fairly simple change.
>
> 3. FetchStatus permissions
> An assumption in the existing cache manager in OpenAFS is that
> FetchStatus on files is allowed if the directory was readable. If
> file ACLs are enforced in FetchStatus, this can result in inconsistent
> behaviour that depends on whether the status information for a file is
> already in cache or not. One solution is to be more permissive - the
> question is if it's acceptable to allow FetchStatus to succeed on the
> file server regardless of the file ACL, as long as the parent
> directory is readable by the requesting user.
>
> 5. "DFS" mode
> Testing has been done with current OpenAFS clients, and some
> mechanisms are proposed to ensure that they work correctly as-is. For
> instance, the VLF_DFSFILESET is set in the VLDB to work around some
> assumptions made by the current OpenAFS client code. Clients
> therefore treat the volume as a DFS fileset, and some DFS specific
> RPCs need to be implemented on the server side.
>
> Some concerns:
> - Similar testing has not been done with other client implementations
> (kafs, arla), so it's unclear how they'll behave in general and with
> this workaround, or whether other workarounds would be needed for them.
> - DFS mode might have some subtle behaviour changes, for instance with
> implicit permissions based on owner and mode bits, etc.
> - "ACL-aware" OpenAFS clients could be made to use "AFS" mode despite
> the DFS flag, for instance based on the file server capabilities.
> They would also get fixes in the few places where there are
> assumptions about permissions coming from the directory.
>
> 6. Volume moves.
> There's some minor adjustment needed in the dump format - so far I'm
> using an optional ACL id tag and an optional ACL data tag with file
> vnodes. An ACL-aware server can generate old and new formats and
> determine the right one to use through capabilities - or could also
> get a hint from a command-line option that sets a dump flag.
> There is a potential loss of information (the file ACLs) if we move a
> volume from a new server with ACLs to an old one. So I'm wondering if
> anything should be done to prevent or warn about this, and if so, what
> mechanism would be available to force it to happen, since it would be
> a useful operation in some cases.
>
> Thanks!
> Marc
>
> _______________________________________________
> AFS3-standardization mailing list
> AFS3-standardization@openafs.org
> http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
>