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