ACL: 'exclusive' stops the search downward, but not always?

[Paweł Dzierżanowski]

After years of digging through Gerrit’s Access Controls documentation - especially the Permission evaluation reference section - I finally reached a point where I felt pretty comfortable with it ;)
That lasted until today, when I realized there might be an inconsistency between the reference and the actual implementation of how BLOCK works… or maybe I still don’t fully understand it.

The docs say:
"For blocking access, all rules marked BLOCK are tested, and if one such rule matches, the user is denied access."

But then, regarding the double use of exclusive, they add:
"When looking at BLOCK, ‘exclusive’ stops the search downward."

So… are all blocking rules evaluated or not?
Based on my tests, it seems they are - and that exclusive doesn’t actually stop the downward search:

projA:
refs/*:
ALLOW read user1
ALLOW read user2

projB: (inheritFrom projA)
refs/*:
exclusiveGroupPermissions = read
BLOCK read user1
ALLOW read user2

projC: (inheritFrom projB)
refs/*
BLOCK read user2

Result: user2 can see projC

For me, I prefer the actual implementation
(it feels natural that BLOCK always works, and lower-level projects are not prevented from extending the blocked group), but then the statement
" ‘exclusive’ stops the search downward" is imprecise.

I hope it is not an implementation bug, because I'd like to rely on BLOCK to work like it works today ;)

Paweł

[Paweł Dzierżanowski]

On Monday, January 26, 2026 at 9:26:56 AM UTC+1 Paweł Dzierżanowski wrote:

Result: user2 can see projC

Oh my, I wrote the other way: the result is *user2 cannot see projC* 
which proves that BLOCK in projC works, and 'exclusive' doesn't stop the search downward. 

Paweł

[Björn Pedersen]

Only matching blocks are considered, if I am not mistaken. As the BLOCK on projB does not match, it does not stop BLOCK evaluation.

 

Paweł

[Sven Selberg]

I think you are correct (or I'm also mistaken), this is what makes `exclusiveGroupPermissions` so confusing and not very usable (IMOHO).

At $DAY_JOB we advice against using `exclusive` and `Deny` in ACLs for that exact reason.

 

 

Paweł

[Paweł Dzierżanowski]

On Tuesday, January 27, 2026 at 8:37:34 AM UTC+1 Sven Selberg wrote:

On Monday, January 26, 2026 at 3:46:32 PM UTC+1 Björn Pedersen wrote:

Paweł Dzierżanowski schrieb am Montag, 26. Januar 2026 um 09:42:19 UTC+1:

On Monday, January 26, 2026 at 9:26:56 AM UTC+1 Paweł Dzierżanowski wrote:

Result: user2 can see projC

Oh my, I wrote the other way: the result is *user2 cannot see projC* 
which proves that BLOCK in projC works, and 'exclusive' doesn't stop the search downward. 

Only matching blocks are considered, if I am not mistaken. As the BLOCK on projB does not match, it does not stop BLOCK evaluation.

I think you are correct (or I'm also mistaken),

Well, it DOES stop when a block rule matches, because it doesn't make sense to look for more --- one block is enough:)

 

this is what makes `exclusiveGroupPermissions` so confusing and not very usable (IMOHO).

At $DAY_JOB we advice against using `exclusive` and `Deny` in ACLs for that exact reason.

Confusing at first, gets clearer with time. And really useful, I couldn't imagine living without them:)

If my observations are correct, then this statement from the Permission evaluation reference:

"When looking at BLOCK, ‘exclusive’ stops the search downward." 

should be something like this:
"When looking at BLOCK, ‘exclusive’ stops the search in the current project, and continues the search in downward projects."