[OpenAFS] Re: Ideas for finer grain set acl controls

[Andrew Deason]

On Fri, 30 Oct 2009 13:20:12 -0400
Jeffrey Altman <jaltman@secure-endpoints.com> wrote:

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

So, after having thought about this, I like general direction of
something like a volume-level administrator-set ACL, but it doesn't
quite work in two specific cases. That is, we don't really have a way to
specify, in an ACL, negative rights specifically for the anonymous user,
or specifically for someone who gets rights via only system:authuser.
Obviously, specifying negative rights for s:anyuser/authuser will just
remove rights for everybody.

For the s:anyuser case, we could allow you to specify 'anonymous' in the
volume ACL (why do we not allow this in normal ACLs, anyway? just
limitations of ptserver return codes?), which would allow you to take
away rights specifically from unauthenticated access. However, I can't
think of any way to do something similar for the s:authuser case.

My current thinking of a way around this is to have a volume-level ACL
that is just applied after any regular ACL, but also have a special case
for s:anyuser/authuser (and any system:authuser@* groups). In these
special cases, instead of adding them to the negative part of a
volume-wide ACL, you limit the acquired rights when you encounter that
group in a positive ACL entry on a directory.

That probably wasn't clear, so let me try an example. To prevent people
from giving write access to project:mayhem on volume user.rpaulson,
you'd do someting like

 vos setacl -vol user.rpaulson -acl project:mayhem idwka -neg

So whenever access is computed from an ACL, you also apply the negative
ACL entry for project:mayhem, preventing idwka access.

To prevent people from giving write access to system:anyuser on volume
user.rpaulson, you'd do something like

 vos restrictacl -vol user.rpaulson -id system:anyuser -maxrights rl

Now, whenever access is computed from an ACL, if the ACL user entry
matches system:anyuser (-101), we logically AND the rights in that entry
with 'rl', so you cannot give system:anyuser any rights besides rl. This
method would be applicable to groups like s:anyuser, s:authuser@*, and
probably host IP groups.

Does this make everyone happy? A clearer proposal (and an improved
interface) will need to be written to explicitly define all of this
stuff, but this is my general idea.

-- 
Andrew Deason
adeason@sinenomine.net