Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[stellation-res] Access control list inheritance behavior question 
I've finally got some time to implement ACLs for the repository. I'm
working on implementing the inheritance behavior. In the docs we've
written so far,  we haven't completely specified the ACL inheritance
behavior. There are a couple of variations, and I'm unsure of which
one is really what we want.

There are three possible behaviors that make sense to me:

(1) Inheritance as immediate copy. In this scheme, when we create a new
  repository entity, the ACL inheritance means that a new ACL is created
  for the new entity by copying the ACL of its parent. In terms of using
  the system, this means that modifying the ACL of the parent *never*
  has an effect on the child.

(2) Inheritance as lazy copy. There are two variants here.   The
  behavioral effect of these is that changes to the parent ACL
  are reflected in the child *until* you specifically do something
  to make the lists be distinct.

  (2a) Automatic ACL copy on child modification: In this scheme, when we
  create a new repository entity, it uses the *same* ACL as its parent.
  When you modify the ACL of the child, it creates a copy of the parent
  ACL, and modifies that. 

  (2b) Explicit ACL copy: In this scheme, when we create a new
   repository entity, it uses the *same* ACL as its parent. It continues
   to use exactly the same ACL as its parent until the user explicitly
   asks the system to create an ACL for the child; when the user does
   so, it copies the parents ACL. So until the user explicitly copies
   the ACL, changing the parent ACL and changing the child ACL are one
   and the same. Once the user copies the ACL, it behaves as in (1).

(3) Inheritance as ACL delta. This is closest to a object inheritance
  behavior. Here, when you create a new repository entity, we create a
  a new ACL for it; and that new ACL references the parent ACL. The 
  new ACL consists of a set of deltas against the ACL of the parent. 

  The effect of this is that changes to the parent *always* effect the
  ACL of the child, but changes to the child do not effect the ACL of
  the parent.

Pros and cons: 

There's a lot of niceness about (3). The catch is that
from an administrators point of view, it's difficult to make it work so
that (3) does *quite* what you might expect.  For example, if as an
administrator, you withdraw checkin privileges for a group, that will
remove checkin privileges from *most* places. But here's where it'll
go wrong.  A user forks branch "A" off of main. For branch "A", they
remove checkin privileges from group "g". Then someone forks "B" off of
"A", and they *add* checkin privileges for group "g".  Now an
administrator wants to withdraw all checkin privs for "g". They do it on
"main", which is the parent of all the others. "g" still has
checkin privileges on "B". So while in theory, (3) feels right, I think
it's likely to cause confusion by misleading people into thinking they
can do something by modifying a parent ACL that they can't really do
that way. So I'm not sure that I want to do it this way...

I'm not particularly wild about either of the lazy copy methods. The
abrupt change from inherited behavior to independent behavior is just
not going to be intuitive.

(1) is very inflexible, but it is the easiest to understand.

So I'm mostly vacillating between (1) and (3), but I could be
convinced to go with (2a) or (2b) if you folks strongly prefer it.

	-Mark




-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email: markcc@xxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part

Back to the top