Hi Marc, ----- Original Message ----- From: "Marc Dionne" <[email protected]>
> 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 [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
