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