Submodule Subscription ACL issues

[Jeff]

Hi all,

We're running into an issue with Submodule Subscriptions ACL's after upgrading from 2.12 to 2.14.  I'm looking for some guidance or advice, please.  First a little background:

We manage a large number of Gerrit repositories across a few different instances using a delegated permission model and standardized permissions per-server. For the most part, all of our repositories are open for read access to all registered users of the system.  We have a few repositories which are "protected" - these are read-restricted to only specific users who are granted access at the per-project level.  All of these projects inherit their permissions from a Protected Parent repo (deny on read to Registered Users).

The Administrators group owns every project on each server.  We have in-house tooling that builds out these repositories, and can rewrite their permissions across each server as needed.  Each repository has an Administrators group that owns the other groups used for that specific repository, allowing them to grant or remove access to a specific function by adding or removing people from the standardized groups.

As of the 2.14 upgrade, we're facing issues with submodule subscriptions.  Ultimately, I'd like to let all of our non-protected projects be subscribed to by any other project on the server, while I'd like to restrict the protected projects to not allow them to be subscribed to at all.  It seems that I can grant these permissions at either the All-Projects, the Protected Parent Level, or individual projects level.  However, I don't see a way to grant the submodule subscription permission for all superprojects.  Is there a way to blanket this permission, or does each superproject need to be granted individually?

Ex:

[allowSuperproject "<superproject>"]
    matching = <refspec>

Is there a way to wildcard <superproject>?

Thank you,

Jeff

[Doug Luedtke]

On Monday, September 25, 2017 at 10:41:08 AM UTC-5, Jeff wrote:

It seems that I can grant these permissions at either the All-Projects, the Protected Parent Level, or individual projects level.  However, I don't see a way to grant the submodule subscription permission for all superprojects.  Is there a way to blanket this permission, or does each superproject need to be granted individually?

That is a good question.

Anyone have an answer? 

[Doug Luedtke]

How bad of a performance impact would adding a new Parent between all of the unprotected repos and All-Projects that includes the allowSuperproject for each of the unprotected repos? The list of repos would be close to 2000 repos. And then each would inherit the list of 2000 repos. That sounds like it would be bad for performance.

Thoughts?

[Jonathan Nieder]

> The list of repos would be close to 2000 repos.

When you submit a change in any of the unprotected repos, Gerrit would search those 200 repos for a corresponding ref that has the target unprotected branch as a submodule. So alas, I'd expect this to significantly slow down submits.

Suppose the unprotected repos have a common parent Unprotected-Projects. It sounds to me like you'd like a self-service way for users to add an allowSuperproject stanza pointing to their new superproject either (A) to Unprotected-Projects or (B) to the specific unprotected projects they want to subscribe to. It could even be something that should happen automatically when they push a superproject. That sounds like a reasonable thing to want. I'd be happy to review a change adding such a facility, either in core or in a plugin.

That way, you'd get the ability to subscribe to arbitrary unprotected projects as submodules, without the performance cost.

Thanks and hope that helps,

Jonathan

чт, 28 сент. 2017 г. в 11:48, Doug Luedtke <douglas...@gmail.com>:

How bad of a performance impact would adding a new Parent between all of the unprotected repos and All-Projects that includes the allowSuperproject for each of the unprotected repos? The list of repos would be close to 2000 repos. And then each would inherit the list of 2000 repos. That sounds like it would be bad for performance.

Thoughts?

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.