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

[Marc Dionne]

On 06/26/2009 01:11 PM, Jeffrey Hutzelman wrote:
> --On Thursday, June 25, 2009 09:48:49 PM -0400 Marc Dionne
> <marc.c.dionne@gmail.com> wrote:
>
>> 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.
>
> This massively violates the principle of least surprise, because it
> changes the behavor for existing AFS users to one where changing the ACL
> on a directory does not actually have any effect on who has what access
> to files within that directory. This seems unacceptable to me.

I don't completely disagree, but new behaviour will necessarily be 
introduced somehwere, and I suspect that what constitutes "least 
surprise" may well vary from user to user.  Which is why it's good to 
get input from various people on this point.

>> 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.
>
> This model is somewhat limited, but is simple and easy to understand.
> And, in fact, a client _can_ tell whether an ACL has been previously set
> on a file, because ACL manipulation operations should always act on the
> actual ACL, not the effective one, so fetching the ACL of a file that
> doesn't have one will result in some appropriate error.

Ah, hadn't thought of that possibility.  That's a change from the 
current behaviour which is to return the parent ACL, but this might not 
be something that too many things rely on.
BTW as described, this would have the same issue for you as A., since 
setting the directory ACL won't necessarily give you access to all files.

> If this approach were adopted, I'd recommend having a way to "unset" the
> ACL on a file, so it goes back to inheriting from its parent.

Yes, that would be needed.  With a new RPC this could be easily handled.

>> E. Other...?
>
> I'd love to see a partial-inheritance model, where a file ACL can
> inherit from its containing directory with some overrides. This could be
> either copy-inheritance, where the parent ACL is copied the first time a
> change is made, after which it is fully independent, or "true"
> inheritance, where changes to the inherited ACL continue to affect the
> effective ACL of the file (the latter, of course, could be implemented
> either by examining both file and directory ACL's when performing access
> checks, or by updating file ACL's whenever the directory ACL changes;
> this is an implementation optimization tradeoff).

That sounds very similar to B. or D.
As you say, actually storing the effective ACL or computing it is an 
implementation issue.

>> 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.
>
> There are OpenAFS-specific implementation issues here. The OpenAFS
> fileserver's on-disk format, and the tools that validate that format,
> make the assumption that a file can have only one parent directory. It
> may look simple to change this, but if you don't work through all of the
> implications, yoy may end up in a situation where people create
> directory structures that the salvager destroys.

Ok, that's good to know, I'll see if I can experiment.  Of course a new 
file server would have its own salvager and tools fixed to deal with 
this, but there could be danger when moving the volume elsewhere or 
accidentally using old versions of some tools.

>> 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.
>
> I imagine most other clients don't implement the DFS-mode behavior at
> all, and so if they apply some of the same optimizations that OpenAFS
> does, such as assuming that a user has the same rights on all files with
> the same parent, then they will handle cached access rights incorrectly.

That's probably the case, as it probably also is with the OpenAFS 
Windows clients.

>> - DFS mode might have some subtle behaviour changes, for instance with
>> implicit permissions based on owner and mode bits, etc.
>
> No; the AFS cache manager does not ever do this kind of second-guessing.
> It depends on the fileserver/translator to tell it what the user's
> effective rights are on each vnode.

Well there's quite a bit of logic for files in afs_AccessOK() 
(afs_vnop_access.c) that's skipped in DFS mode - I'm assuming there's at 
least some cases where there's an impact there.

>> 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.
>
> The right thing to do here is to include the ACL data in new,
> non-critical flags drawn from the proper range so they can be ignored by
> entities which do not understand them.

The whole dump discussion is informative, thanks.  I wonder however how 
much of what you describe is actually taken into account and implemented 
in the current OpenAFS volserver and tools.  In particular, will they 
correctly skip over unknown tags based on the expected length from the 
tag ranges, etc.

Marc