RE: [stellation-res] Access control list inheritance behavior question

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> >Chu-Carroll
> >Sent: September 28, 2002 6:51 AM
> >To: stellation-res@xxxxxxxxxxxxxxx
> >Subject: [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.
One way you could make this more flexible is to take advantage of the
parent-child relationship between branches. Thus you could apply a change to
a single branch only, to a branch and all its' children, or to a subset of
the children of a given parent based on a regular expression matching
process. This sould retain the conceptual simplicity of (1) but make the
administrator's job a lot easier. Using yur example, the administrator could
then say remove checkin priveleges from group g whereever it may appear. I
would like (1) with the extension I am proposing.

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

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx