[OpenAFS] Ideas for finer grain set acl controls
Jim Rowan
jmr@computing.com
Fri, 30 Oct 2009 10:27:23 -0500
On Oct 30, 2009, at 7:54 AM, Michael Meffie wrote:
> Hello,
>
> Andrew, Tom, and I would like to discuss and solicit feedback on
> some ideas we have been considering to strengthen OpenAFS access
> controls, especially for sites which provide AFS service over the
> public internet.
>
I like the additional capabilities offered by this concept. In one of
my past lives I had a requirement (which went unfilled) for such
controls. The examples you gave made sense, except that there seems
to be a hole.
>
> We need to take into consideration nested groups (aka
> supergroups). For example, assume for some reason, the group
> system:anyuser is a member of the group project:mayhem. This
> creates a complication in that a user could set the ACLs for
> project:mayhem, and transitively effect members of system:anyuser.
> Consider a volume called project.mayhem, which is mounted at as
> /afs/example.com/project/mayhem.
>
> setpolicy
> -grant
> -user system:anyuser
> -set-rights rl
> -for-user system:anyuser
> -in-volume project.mayhem
>
> pts adduser example:staff project:mayhem
> pts adduser system:anyuser project:mayhem
>
> Since the pts group system:anyuser now a member of the
> project:mayhem group, then the setting of the ACLs for
> project:mayhem would also need to be restricted,
>
> cd /afs/example.com/project
> fs setacl mayhem project:secret rlidwk
I think you meant "fs setacl mayhem project:mayhem rlidwk"
>
> 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.)