On Sun, 17 Jan 2010 21:52:05 +0000 Adam Megacz <a...@megacz.com> wrote:
> > Andrew Deason <adea...@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:authu...@realm for all > realms known to this one. You cannot put system:anyuser, system:authuser, or system:authu...@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 adea...@sinenomine.net _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
