[AFS3-std] Per-file ACLs - a few items for discussion

[Marc Dionne]

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