Access Controls - read access to HEAD ref and nothing else

[atav...@yext.com]

Hi folks,

In our deployment, Registered Users have read access on "refs/*" on all projects (i.e. via "All-Projects" project's access controls).

For one particular repo, I would like a specific group to only have read access to "refs/heads/main" of that repo -- i.e. if a user of that group runs `git clone --mirror <repo-url>` (or `git ls-remote <repo-url>` in an existing clone), all they get is "refs/heads/main".

So far, I have not found a way to grant that access without also granting read access to  at least refs/changes/*.

A few things I've tried without success in the project.config of that specific repo:

Attempt 1 - DENY all & ALLOW the more specific ref:

[access "refs/*"]
       read = deny group GroupWithLimitedAccess

[access "refs/heads/main"]
       read = group GroupWithLimitedAccess

Attempt 2 - BLOCK all & override the specific ref with an exclusive ALLOW:

[access "refs/*"]
       read = block group GroupWithLimitedAccess

[access "refs/heads/main"]

       exclusiveGroupPermissions = read

       read = group Registered Users

Attempt 3 - explicitly BLOCK the namespaces I want to hide:

[access "refs/changes/*"]
       read = block group GroupWithLimitedAccess
[access "refs/users/*"]
       read = block group GroupWithLimitedAccess

[access "refs/cache-automerge/*"]
       read = block group GroupWithLimitedAccess

A few non-ACL options I've looked into:

Git's native uploadpack.hideRefs functionality (doesn't appear to be applicable on subsets of clients).

The git-refs-filter plugin (doesn't seem to have per-project configuration, and does extra filtering on closed changes I don't need).

Any help -- including confirmation that what I'm trying to do isn't currently supported -- would be appreciated.

Thanks in advance!

[Paweł Dzierżanowski]

poniedziałek, 1 kwietnia 2024 o 18:12:28 UTC+2 atav...@yext.com napisał(a):

Any help -- including confirmation that what I'm trying to do isn't currently supported -- would be appreciated.

There is a fix described in v3.3 release note [1] :

"(...) That was problematic, because it bypassed documented behavior [2] where a user should only have access to a change if he can see the destination ref"

I couldn't find the place exactly where it is described in the linked access control documentation, but this note in the release docs seems to indirectly confirm that it is not possible to achieve what you want

Paweł

[1] https://www.gerritcodereview.com/3.3.html#security-fixes

[2] http://gerrit-documentation.storage.googleapis.com/Documentation/3.3.1/access-control.html

[Sven Selberg]

On Wednesday, July 24, 2024 at 5:03:16 PM UTC+2 Paweł Dzierżanowski wrote:

poniedziałek, 1 kwietnia 2024 o 18:12:28 UTC+2 atav...@yext.com napisał(a):

Any help -- including confirmation that what I'm trying to do isn't currently supported -- would be appreciated.

I don't think this use-case is supported, it is combersome to "un-allow" read access to all but a  specific set of refs.

I would try a negative look-ahead in the ref-pattern in the access section. Previously Gerrit didn't support adding a negative look-ahead through UI and REST but you can push a project.config with a negative look-ahead directly to refs/meta/config.
Something like (untested)
```

[access "^refs/(?!heads/main)$"]

    read = block group GroupWithLimitedAccess

```

 IIRC this may make it cumbersome to update refs/meta/config for this project so you might want to add this special rule in a meta-project before.

[Paweł Dzierżanowski]

czw., 25 lip 2024 o 10:00 Sven Selberg <sven.s...@axis.com> napisał(a):

On Wednesday, July 24, 2024 at 5:03:16 PM UTC+2 Paweł Dzierżanowski wrote:

poniedziałek, 1 kwietnia 2024 o 18:12:28 UTC+2 atav...@yext.com napisał(a):

Any help -- including confirmation that what I'm trying to do isn't currently supported -- would be appreciated.

I don't think this use-case is supported, it is combersome to "un-allow" read access to all but a  specific set of refs.

I would try a negative look-ahead in the ref-pattern in the access section. Previously Gerrit didn't support adding a negative look-ahead through UI and REST but you can push a project.config with a negative look-ahead directly to refs/meta/config.
Something like (untested)
```

[access "^refs/(?!heads/main)$"]

    read = block group GroupWithLimitedAccess
```

I believe OP wanted to allow reading from refs/heads/main but at the same to hide all refs/changes (including the changes targeted for main)

[Sven Selberg]

True, if block for "refs/changes/*" isn't honored that wouldn't fulfill that requirement.
Then I honestly don't think a maintainable solution with just Gerrit is possible. You would need to do something like serving that repo from somewhere else for that group.

 Don't know how strong it would be but you could make an case that `Block` should be honored for change refs "sure you have read access to main but you are blocked from everything under "refs/changes/*".
refs/changes/* is (at least close-to) a db ref in Gerrit so it would potentially make things a lot more complicated.