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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
