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

[florin@xxxxxxxxx (Florin Iucha)]

On Sat, Sep 28, 2002 at 10:50:41AM +0000, Mark C. Chu-Carroll wrote:
> 
> 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.

I suggest we follow the "principle of least astonishment" and go with
the POSIX behavior for ACLs - I have no clue what it is, but supposedly
they thought about it and some people/admins are already familiar with
it. Or come with a good reason why not.

Now what I see is that for compound artifacts there are extra actions
that are not available for atoms like "list contents", "add item",
"remove item", so it might make sense for a parent to have a "default
ACL for children".

I am -1 for 3: it is too much magic - and magic can be dangerous. If
they want to affect a whole tree with a single command, give them "-R".

florin

-- 

"If it's not broken, let's fix it till it is."

41A9 2BDE 8E11 F1C5 87A6  03EE 34B3 E075 3B90 DFE4

Attachment: pgpfJdSiGL7ic.pgp
Description: PGP signature