Overrule BLOCK with ALLOW on the same project
It was impossible to block a permission for a group and allow the same
permission for a sub-group of that group as the block always won over an
allow. For example, it was impossible to block the "Forge Committer"
permission for all users and then allow it only for a couple of
privileged users.
This change gives an ALLOW permission priority over a BLOCK permission
when they are defined in the same access section of a project. To
achieve the above mentioned policy we define:
[access "refs/heads/*"]
forgeCommitter = block group Anonymous Users
forgeCommitter = group Privileged Users
Across projects the BLOCK permission still wins over an ALLOW
permission. This way one cannot override an inherited BLOCK in a
subproject.
Overruling of BLOCK with ALLOW also works for labels i.e. permission
ranges. If a dedicated Verifiers group need to be the only group who can
vote in the Verified label and we must ensure that even project
owners cannot change this policy then we define the following in a
common parent project:
[access "refs/heads/*"]
label-Verified = block -1..+1 group Anonymous Users
label-Verified = -1..+1 group Verifiers
Change-Id: I8e27b6b060d60bb8a846ce62d0338f613a7d7a3e
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>
Signed-off-by: Edwin Kempin <edwin.kempin@sap.com>
diff --git a/Documentation/access-control.txt b/Documentation/access-control.txt
index 70e9cfd..9b97b94 100644
--- a/Documentation/access-control.txt
+++ b/Documentation/access-control.txt
@@ -1109,8 +1109,9 @@
~~~~~~~~~~~~~~~~~~~
The 'BLOCK' rule blocks a permission globally. An inherited 'BLOCK' rule cannot
-be overridden in the inheriting project. Any 'ALLOW' rule which conflicts with
-an inherited 'BLOCK' rule will not be honored. Searching for 'BLOCK' rules, in
+be overridden in the inheriting project. Any 'ALLOW' rule, from a different
+access section or from an inheriting project, which conflicts with an
+inherited 'BLOCK' rule will not be honored. Searching for 'BLOCK' rules, in
the chain of parent projects, ignores the Exclusive flag that is normally
applied to access sections.
@@ -1131,6 +1132,26 @@
every vote from '-INFINITE..min' and 'max..INFINITE'. For the example above it
means that the range '-1..+1' is not affected by this block.
+'BLOCK' and 'ALLOW' rules in the same access section
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When an access section of a project contains a 'BLOCK' and an 'ALLOW' rule for
+the same permission then this 'ALLOW' rule overrides the 'BLOCK' rule:
+
+====
+ [access "refs/heads/*"]
+ push = block group X
+ push = group Y
+====
+
+In this case a user which is a member of the group 'Y' will still be allowed to
+push to 'refs/heads/*' even if it is a member of the group 'X'.
+
+NOTE: An 'ALLOW' rule overrides a 'BLOCK' rule only when both of them are
+inside the same access section of the same project. An 'ALLOW' rule in a
+different access section of the same project or in any access section in an
+inheriting project cannot override a 'BLOCK' rule.
+
Examples
~~~~~~~~
@@ -1160,6 +1181,23 @@
pushTag = group Project Owners
====
+Let only a dedicated group vote in a special category
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Assume there is a more restrictive process for submitting changes in stable
+release branches which is manifested as a new voting category
+'Release-Process'. Assume we want to make sure that only a 'Release Engineers'
+group can vote in this category and that even project owners cannot approve
+this category. We have to block everyone except the 'Release Engineers' to vote
+in this category and, of course, allow 'Release Engineers' to vote in that
+category. In the "`All-Projects`" we define the following rules:
+
+====
+ [access "refs/heads/stable*"]
+ label-Release-Proces = block -1..+1 group Anonymous Users
+ label-Release-Proces = -1..+1 group Release Engineers
+====
+
[[conversion_table]]
Conversion table from 2.1.x series to 2.2.x series
--------------------------------------------------
