[AFS3-std] Re: Methods of Restricting AFS3 ACL rights (correctness+performance)

[Andrew Deason]

On Sun, 17 Jan 2010 21:52:05 +0000
Adam Megacz <adam@megacz.com> wrote:

> 
> Andrew Deason <adeason@sinenomine.net> writes:
> > 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.
> 
> If you are talking about my transitive ACLs proposal, then the new
> foo/dir is still subject to the transitive acl on foo/.

I said you put a transitive ACL on foo/dir.

But if you put a transitive ACL on foo, fine. Then 'mv foo foo.old ;
mkdir foo ; rsync -a foo.old/ foo/' (or whatever, accounting for
mountpoints and such) and it's bypassed.

> > 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).
> 
> No, they can all be done in O(log N) by propagating the data up and
> down the tree on demand.  If you want the gory details ask and I will
> explain how.

Where N is the number directory _levels_ you are deep? (Not the total
number of files/directories in the volume). Yes, I would like to see
that. If you set a transitive ACL on dir X, and dir X has N levels of
descendants (that is, around N^2 vnodes with X as an ancestor), I would
like to see how it is possible to mark the descendant vnodes in only
log N time.

> >>   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).
> 
> Then create a supergroup containing system:authuser@realm for all
> realms known to this one.

You cannot put system:anyuser, system:authuser, or system:authuser@cell
in another group. Er, well, you _can_, but it doesn't do anything
currently. anyuser/authuser privs are acquired a bit differently than
normal group membership.

If you could, this would've made 'method 2' trivially bypassable by
putting the special groups in a supergroup.

-- 
Andrew Deason
adeason@sinenomine.net