[OpenAFS] Re: Ideas for finer grain set acl controls
Wed, 4 Nov 2009 11:30:29 -0600
On Fri, 30 Oct 2009 10:27:23 -0500
Jim Rowan <email@example.com> wrote:
> > fs: You don't have the required access rights on mayhem
> I don't think you've solved this part of the problem. I don't know
> how to solve it, either.
> Since the restrictive policy on adding ACLs is evaluated at the time
> that the ACL is modified, and the membership of the super-group can
> be modified either before or after that event, this approach isn't
> going to result in any reasonable level of assurance that the ACLs
> are enforcing the intended policy (regarding access to the
> filesystem). It seems that as long as supergroups are in use in the
> cell, this is a potential hole.
> In fact, this same issue exists with respect to individual members
> of a normal group as well. (A policy preventing people from giving
> jane write access to some object would be circumvented if jane was
> added after the fact to a group that is allowed to be given write
> access to that object.)
There is a way around this. This isn't a security hole; you just
restricted the wrong thing (I got this wrong for awhile, too).
If you want to prevent everyone in project:mayhem from getting idwka
rights, you don't set the ACL policy to prevent people from setting
'project:mayhem idwka'. Instead, you give project:mayhem negative idwka
rights on all directories in the volume, and then set the ACL policy
such that users cannot take away the negative rights.
Therefore, the 'volume ACL policy' method is capable of doing everything
that the 'volume-level ACL overlay' method that Jeffrey (and later, I)
described, I believe. There are still pros and cons of each method; I'll
try to get something together to illustrate them.