How does gerrit resolve the priorities of related access-control-rules?

[lfree]

For example, userA is both the Project Owner and Change Owner.

I add these two rules: 

• Project Owner is allowed to Label: Review -2 +2
• Change Owner is blocked(or denied) to Label: Review -2 + 2

Then what if userA push a commit to refs/for/master branch for review? Whether userA can review +2 or not?

I tried this, the result is he can. But why? Are there any regulations for this behavior?

[Edwin Kempin]

If BLOCK and ALLOW rule are on the same project, the ALLOW rule wins.

A BLOCK rule on a parent project cannot be overwritten by ALLOW rules on child projects.

This semantic was changed with 2.14 [1,2]. Before this change ALLOW rules only overruled BLOCK rules on the same project if they were defined on the same ref, or ref pattern.

[1] https://gerrit-review.googlesource.com/111796

[2] https://gerrit-review.googlesource.com/85250

 

--
--
To unsubscribe, email repo-discuss+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[lfree]

Hi Edwin, thanks for reply. 

I have read the 2.14 release notes from the urls you provided. I understand and agree with the change: 

This change makes it possible to allow a permission for a specific ref and to

block the same permission for all other refs. For example, it is now possible to

allow all users to push changes for review, but to block all direct pushes:

---

  [access "refs/*"]

    push = block group Anonymous Users

  [access "refs/for/*"]

    exclusiveGroupPermissions = push

    push = group Registered Users

---

I think that is reasonable because refs/for/* is more specific then refs/*.

But when allow rule and block rule are on the same refs of the same project, does it suitable to simply let allow rule win the conflict?

On Thursday, July 6, 2017 at 2:20:01 PM UTC+8, Edwin Kempin wrote:

On Thu, Jul 6, 2017 at 2:45 AM, lfree <xh.dre...@gmail.com> wrote:

For example, userA is both the Project Owner and Change Owner.

I add these two rules: 

• Project Owner is allowed to Label: Review -2 +2
• Change Owner is blocked(or denied) to Label: Review -2 + 2 

Then what if userA push a commit to refs/for/master branch for review? Whether userA can review +2 or not?

I tried this, the result is he can. But why? Are there any regulations for this behavior?

If BLOCK and ALLOW rule are on the same project, the ALLOW rule wins.

A BLOCK rule on a parent project cannot be overwritten by ALLOW rules on child projects.

This semantic was changed with 2.14 [1,2]. Before this change ALLOW rules only overruled BLOCK rules on the same project if they were defined on the same ref, or ref pattern.

[1] https://gerrit-review.googlesource.com/111796

[2] https://gerrit-review.googlesource.com/85250

 

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

[Edwin Kempin]

On Thu, Jul 6, 2017 at 10:08 AM, lfree <xh.dre...@gmail.com> wrote:

Hi Edwin, thanks for reply. 

I have read the 2.14 release notes from the urls you provided. I understand and agree with the change: 

This change makes it possible to allow a permission for a specific ref and to

block the same permission for all other refs. For example, it is now possible to

allow all users to push changes for review, but to block all direct pushes:

---

  [access "refs/*"]

    push = block group Anonymous Users

  [access "refs/for/*"]

    exclusiveGroupPermissions = push

    push = group Registered Users

---

I think that is reasonable because refs/for/* is more specific then refs/*.

But when allow rule and block rule are on the same refs of the same project, does it suitable to simply let allow rule win the conflict?

Yes, this was always like this. This allows you to define rules like: Permission A is blocked for everyone except for group X, e.g. you can block direct push to refs/meta/config for all users, except for Administrators:

[access "refs/meta/config"]

    push = block group Anonymous Users

    push = group Administrators

 

If the ALLOW rule would not win in this case, this would be difficult to set this up. Basically then you would need to have a group which contains all users except Administrators, and then block that group. But such a group would be difficult to maintain.

On Thursday, July 6, 2017 at 2:20:01 PM UTC+8, Edwin Kempin wrote:

On Thu, Jul 6, 2017 at 2:45 AM, lfree <xh.dre...@gmail.com> wrote:

For example, userA is both the Project Owner and Change Owner.

I add these two rules: 

• Project Owner is allowed to Label: Review -2 +2
• Change Owner is blocked(or denied) to Label: Review -2 + 2 

Then what if userA push a commit to refs/for/master branch for review? Whether userA can review +2 or not?

I tried this, the result is he can. But why? Are there any regulations for this behavior?

If BLOCK and ALLOW rule are on the same project, the ALLOW rule wins.

A BLOCK rule on a parent project cannot be overwritten by ALLOW rules on child projects.

This semantic was changed with 2.14 [1,2]. Before this change ALLOW rules only overruled BLOCK rules on the same project if they were defined on the same ref, or ref pattern.

[1] https://gerrit-review.googlesource.com/111796

[2] https://gerrit-review.googlesource.com/85250

 

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

--
--
To unsubscribe, email repo-discuss+unsubscribe@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+unsubscribe@googlegroups.com.

[lfree]

On Thursday, July 6, 2017 at 4:40:38 PM UTC+8, Edwin Kempin wrote:

On Thu, Jul 6, 2017 at 10:08 AM, lfree <xh.dre...@gmail.com> wrote:

Hi Edwin, thanks for reply. 

I have read the 2.14 release notes from the urls you provided. I understand and agree with the change: 

This change makes it possible to allow a permission for a specific ref and to

block the same permission for all other refs. For example, it is now possible to

allow all users to push changes for review, but to block all direct pushes:

---

  [access "refs/*"]

    push = block group Anonymous Users

  [access "refs/for/*"]

    exclusiveGroupPermissions = push

    push = group Registered Users

---

I think that is reasonable because refs/for/* is more specific then refs/*.

But when allow rule and block rule are on the same refs of the same project, does it suitable to simply let allow rule win the conflict?

Yes, this was always like this. This allows you to define rules like: Permission A is blocked for everyone except for group X, e.g. you can block direct push to refs/meta/config for all users, except for Administrators:

[access "refs/meta/config"]

    push = block group Anonymous Users

    push = group Administrators

 

What if I want to define rules like: Permission A is allowed for everyone except for group X? Does the following works?

[access "refs/for/*"]

   submit = group Developers

   submit = block group GreenDevelopers

[Edwin Kempin]

Just put the block rule on a parent project.

[lfree xh]

It can do the work to put the block rule on a parent project. Then I have to create a parent project.

What am trying to express is blocking all except one and allowing all except one are naturally the same thing. But we have to using different methods to implement them here.

If some general rules applied, e.g. "specific before common" or "determine by their orders in the config file", they could be resolved with the consistent way.

Besides, the problem I mentioned in my original post, namely:

 "I am both the project owner and change owner to which conflict rules are applied, then which rule should be preferred if a situation which both rules meet happend?"

could be easily done instead of using the relatively complicated rules.pl

--

dance like nobody's watching……

dreamlover @_@

[Martin Fick]

On Friday, July 07, 2017 07:33:49 AM 'Edwin Kempin' via Repo

and Gerrit Discussion wrote:
> Just put the block rule on a parent project.

This sounds like a design flaw to me. Since we have a
concept of project owners, it seems that it would be
consistent if we ensured that it were possible to setup
guidelines for a project within a project itself, and that a
project owner would never have to edit a parent project's
ACLs since they might not be project owners on the parent
project, and they might not have the permissions to do so.

In other words, it seems that the presumption is that in
order to define ACL rules now, one needs to be the server
administrator?

-Martin

--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation

[Edwin Kempin]

On Fri, Jul 7, 2017 at 6:50 PM, Martin Fick <mf...@codeaurora.org> wrote:

On Friday, July 07, 2017 07:33:49 AM 'Edwin Kempin' via Repo
and Gerrit Discussion wrote:
> Just put the block rule on a parent project.

This sounds like a design flaw to me.

Block rules were specifically designed for allowing administrators to block project owners from allowing certain permissions on child projects [1].

 

   Since we have a
concept of project owners, it seems that it would be
consistent if we ensured that it were possible to setup
guidelines for a project within a project itself, and that a
project owner would never have to edit a parent project's
ACLs since they might not be project owners on the parent
project, and they might not have the permissions to do so.

I agree to this, but I don't think that block rules should be necessary for this.

As said above block rules are intended to be used by administrators to block permissions that should not be used in child projects.

 

In other words, it seems that the presumption is that in
order to define ACL rules now, one needs to be the server
administrator?

First of all I only explained how the permissions work right now.

I agree that improvements are possible.

For the case where you have a BLOCK and an ALLOW rule on the same project and same ref, the ALLOW rule has always been an exception to the block rule. I don't understand why after 6 years this should suddenly be a problem now?

What has changed with [2] is that now an exclusive ALLOW rule on the same project makes an exception to a more generic BLOCK rule too. Please note we are talking about an exclusive ALLOW rule here. The definition of an exclusive rule is that once it is hit, all ACLs on less specific refs are ignored. If you don't want this behavior and you want that the BLOCK rule on the less specific ref is respected, don't make the ALLOW rule exclusive. Alternatively you could put the BLOCK rule on a parent project.

For me the expectation that an exclusive ALLOW rule would be blocked by a BLOCK rule on the same project, but less specific ref is wrong due to 2 reasons:

- exclusive rule means, permissions on less specific refs are ignored (if it behaved differently so far, I would consider this a bug)

- block rule means, permissions on child projects are blocked

Also we have 2 competing needs:

a) a permission is allowed for everyone except a specific group

b) a permission is blocked for all users except a specific group

Currently both of these needs can be achieved, although admittedly a) might not be as comfortable as it could be (block rule on parent project or no use of exclusive allow rule). But before [2] b) was literally impossible. So I see [2] as an improvement, but of course further improvements are certainly possible (but I'm not planning to work on any soon).

Specifically being able to globally block direct push, but allow push for review is an important use case, which wouldn't be possible without [2].

[1] https://gerrit-review.googlesource.com/22061

[2] https://gerrit-review.googlesource.com/85250