[OpenAFS-devel] Re: Methods of Restricting AFS3 ACL rights

[Andrew Deason]

On Sat, 16 Jan 2010 05:10:21 +0000
Adam Megacz <adam@megacz.com> wrote:

> 
> Andrew Deason <adeason@sinenomine.net> writes:
> > The explanation for the various methods now exists as an Internet
> > Draft, and can be found here:
> 
> AFAIK, a volume is the unit of space management, while a directory is
> the unit of access management. [*]

Currently, yes, in a way you could say that. The difference here is that
the described access controls are set by an administrator, not typically
by the users modifying the volume data. In most normal setups assigning
an ACL like these to a subdirectory in a volume is trivially bypassable:

That is, say you set some MAC or 'transitive ACL' or something on path
./foo/dir in a volume. Anyone with the necessary rights can then just
move foo/dir out of the way, create a new foo/dir, and copy the data
from the old foo/dir.

It's also hard for me to imagine someone really wanting such granularity
with these. In my opinion, from the perspective of an administrator I
think I'd find even volume-granularity too much, and per-server would be
fine. But per-volume allows the policy to stay with the data in theory.

> Solving the problem being discussed while retaining this distinction
> would involve:
> 
>   1. Allowing transitive ACLs.  Semantically, a transitive positive
>      (negative) ACL has the same effect as if it were appended to the
>      list of positive (negative) ACLs of every subdirectory.

For a directory N levels deep in a volume, this either makes access
checks take O(N) time (checking all of the parents for transitive ACLs),
or makes mkdir operations take O(N) time and transitive setacl
operations take O(N^2) time (if we mark the transitive ACL on all
subdirectories).

Even ignoring my previous objection about this being bypassable, that's
a tough performance hit. Assuming sparse transitive ACLs could make
those time bounds go down quite a lot, but still...

>   2. Allowing for complement principals.  Semantically, an ACL
>      mentioning the complement of a pts group applies to all users who
>      are not in that group.
> 
> Then one can:
> 
>   fs sa /afs/@cell/web/ !system:authuser a -negative -transitive

This does not _quite_ do what we were aiming for, as this also prevents
'a' access for foreign-cell users (but that may be good enough). To make
this fully flexible you'd need to be able to specify something like
'!(system:authuser || system:authuser@other.cell)' which starts to look
really daunting to me really fast.

I think normal ACLs at a volume-setting work fine for pretty much every
case except: system:anyuser, system:authuser, and some cases of host
ACLs. To solve those, we could go for something like specifying
'complement principals' and the like, or we could use the 'volume ACL
masks' idea described as method 2 in the I-D. They both provide a way to
restrict those groups.

-- 
Andrew Deason
adeason@sinenomine.net