On Fri, 30 Oct 2009 13:20:12 -0400 Jeffrey Altman <[email protected]> wrote:
> Michael: > > Thank you for this proposal. I think you have misnamed it. What > you are proposing is not finer grained ACLs but ACL change control > policies. Well, the idea was that we were making the 'a' bit finer-grained, but I think your point is well taken. > To address the use case properly there needs to be the ability to > apply additional sets of ACLs controlled entirely by the > administrator. Positive ACLs that give privileges that cannot be > restricted and negative ACLs that restrict privileges that cannot be > granted. These would have to be enforced by the file server at > access time. This ensures that changes in group membership do not > bypass the administrator set permissions. Agreed; Jim's objection looks correct (thanks for catching that), and we'll probably need to do something like this instead. My concern with something like this, at least if it's a volume-wide setting, would be how we allow an administrator to override the policy in specific cases (e.g. the admin wants to specify one directory as allowing system:anyuser write access). Storing it in the ACL for the overridden directory means changing the ACL format. But storing it in the per-volume data makes me worry about scalability. Or is such an 'override' functionality not really important? Another way of allowing that would be to actually store the e.g. negative ACL entry in all of the ACLs for the volume, and prevent normal users from removing them... but that has the obvious downside of needing to modify all of the ACLs. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
