My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 710: multiple project parent inheritance
9 people starred this issue and may be notified of changes. Back to list
Status:  Started
Owner:  ----


Sign in to add a comment
 
Reported by nas...@chromium.org, Sep 3, 2010
I find that specifying only one project to inherit access controls from is rather limiting. It'd be nice if we could specify multiple parents and get the union of their access control lists.
Sep 3, 2010
#1 sop@google.com
I'm really terrified of this idea.

Access control rules are too complex as they
stand right now.  Look at issue 708 for just
such an example.  :-(

What happens when there are collisions between
the rules?  Especially with recent changes like
commit 69796cb9b7b205ad5f55f3b1258bde4d60d3fa8c
that blocks permissions by matching parts of the
right?  What if one parent "blocks" the other's
rules?  We would need a sane order to apply them.


Summary: multiple project parent inheritance
Status: AwaitingInformation
Sep 6, 2010
Project Member #2 fredrik....@sonyericsson.com
We currently also have a need to apply rights in a matrix-wise fashion.
We have several internal groups that have divided the projects among them, and then we have external vendors that want to deliver a full platform to these gits.

Example:
Org A owns group of gits, git group A which is sorted under one parent A
Org B owns other group of gits, git group B which is sorted under other parent B
Vendor C wants to deliver a platform, which is a combination of:
1.   one group of gits not owned by Org A or B (easy to classify under separate parent C)
2.   one subset of group A, so many but not all gits
3.   one subset of group B, so many but not all gits
Currently I end up setting rights on a parent C, plus scripting individual permissions to each project found under condition 2 and 3.

I heard something about "tags" or "labels". If we will be able to set rights on labels, the matrix permissions will be doable.


As far as I can tell, we've so far given the highest bidder the right of way, it's already a situation with rules from several stacking parents, isn't it? IIRC we've tested inheritance from parents and grand parents and came out with a highest bidder style combo. That should be repeatable?
That means, if several inherited rules comes in affecting the same primary key (combo of ref_pattern, project, category_id, group_id?), the permissions stack up and grants the most generous offer. Whenever that's a problem (and in practice that's probably most likely to happen with a READ, no?) you need to grant a lower rule specifically in the git to override any inherited value(s).

Maybe you can tell I havn't read the code, I may be wrong in my assumptions. My statement reflects a solution I consider possible if my assumption aren't completely off the scale. Comments on this are most welcome. :)
Apr 13, 2011
#3 nas...@chromium.org
@fredrik, have you started on this change at all?
@sop, you did give the go-ahead for this at gitTogether this year, correct?

We've been looking into doing something similar to this without actually doing the multiple inheritance feature in Gerrit, but we're at the point now where I think the overhead would be too great without native Gerrit support.
May 19, 2011
Project Member #4 nas...@grainawi.org
This is going in on top of the git-store changes.
Status: Started
May 20, 2011
#5 sop@google.com
Martin is working on https://review.source.android.com/22871
Owner: mf...@codeaurora.org
Cc: -mf...@codeaurora.org
Labels: Milestone-2.2.0
Feb 23, 2012
Project Member #6 mf...@codeaurora.org
I gave up on this for a while.  I am removing myself in case someone else wants to pursue it in the meantime.  If you do, it is probably worth looking at my first 2 attempts, but the ACL code has changed drastically since then, that is why I have yet to finish this.
Owner: ---
May 9, 2012
Project Member #7 nas...@codeaurora.org
(No comment was entered for this change.)
Labels: -Milestone-2.2.0
Sign in to add a comment

Powered by Google Project Hosting