[AFS3-std] Per-file ACLs - a few items for discussion
Jeffrey Altman
jaltman@secure-endpoints.com
Sat, 27 Jun 2009 12:15:09 -0400
Marc Dionne 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
>
> Are there documents somewhere that specify the existing protocol with
> that level of detail?
doc/pdf/ contains the documents as written by Transarc. doc/xml/
contains the same docs converted to doxygen so they can be edited.
> 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.
I believe that "fa sa <file>" on old clients should continue to fail
(ENOTDIR)
>
>> 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.
agreed. which is why this forum is the correct place to hold the
discussions.
>
>> 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.
I believe that FetchACL being readonly is ok to extend because that is
the behavior that the Transarc/OpenAFS file servers currently provide
even if it is outside the spec. If we were to start returning ENOTDIR
for files that would be breaking the existing behavior that users expect.
>
>> 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.
I believe that old clients should not see the change in behavior.
>
>> 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).
I do not think the old StoreACL RPC is sufficient to describe the
behaviors. As a result the old clients would be able to set some
behaviors but not others. That would be worse than not permitting them
to set the ACLs at all.
>
>> 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.
>
>> 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.
The important code is src/WINNT/afsd/cm_access.c cm_HaveAccessRights()
which ensures that access tests are only performed on directory
objects. The cm_scache_t and cm_aclent_t infrastructure is present to
support per-file ACLs but the access test is always on the directory
object regardless of what ACL entries exist on a non-directory object.
Looking at Arla, it is aware of the VLF_DFSFILESET flag. However all it
does with it is produce a warning message "get_info: <volume> is really
a DFS volume. This might not work."
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
Jeffrey Altman