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

[Matt W. Benjamin]

Hi Marc,

----- Original Message -----
From: "Marc Dionne" <marc.c.dionne@gmail.com>

> 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.

And most resembles POSIX, as well.  I think this is most attractive for reducing potential
cost of ACL enforcement.

> 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.

POSIX provides for a default ACL attached to directories in a similar way, IIRC.
I think it might be desirable to define conforming, even if it isn't implemented right away.

> 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.

Sounds right to me;  I'll probably get whopped...

> 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.

I suspect that the relationship between stat information and user permissions is tricky
at best, and this solution doesn't seem to make anything worse than it already is.

> 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.

This is new to me.  Can you elaborate on the RPCs?

> 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.

I think (hope) that's expected.

Thanks!
Marc

_______________________________________________
AFS3-standardization mailing list
AFS3-standardization@openafs.org
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization