User has access to subset list of project tags

[Alon Bar-Lev]

Hi,

I have a very strange issue with Gerrit and a specific user.

For some reason a specific user cannot see a specific tag in a project.

The tag is not visible for a specific user in Gerrit user interface nor in `git ls-remote` output.

Other users can see the tag.

We have no specific tag access settings, the tags are quite standard... see the following, the problematic tag is v1.1.2, the rest are visible.

```

 git ls-remote | grep tags
d7aceeeb1b45396d48037ab5db07c55c24e28ce0 refs/tags/v1.0.0
c4a424ac7ae9301401bdd23a3b89f8cc9ab19a0c refs/tags/v1.0.1
f8d5a96e14d3ccf67310b262a64c9aadfe950f51 refs/tags/v1.1.0
4d8391da08d437a37a8021b31122d86cad5dda1d refs/tags/v1.1.1
70cb277cae6110a5b50833bf23717a2ad9680406 refs/tags/v1.1.2     <=====
```

The tag was created via the web user interface.

It is not an index issue as I did rebuild all indexes.

It occured on 3.12.1 and also 3.12.2.

We are using ssh protocol, but it seems unrelated as the web user interface and the git show the same result.

Any clue how to debug this?

Thanks,

Alon

[Alon Bar-Lev]

Hi,

I solved this by adding Read permission at  `refs/*` to Project Owners.

Now all tags are visible.

I am not sure why it should be added and what is special about this specific tag that was hidden.

Thanks,

Alon

[Nasser Grainawi]

On Wed, Aug 27, 2025 at 10:30 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hi,

I solved this by adding Read permission at  `refs/*` to Project Owners.

Now all tags are visible.

I am not sure why it should be added and what is special about this specific tag that was hidden.

Visibility on tags is determined by which branches are visible. So usually this scenario happens when these tags point to commits that are either 1) only on branches the user cannot see or 2) not on any branch (only reachable from the tag).

Nasser

 

Thanks,

Alon

On Wed, 27 Aug 2025 at 19:00, Alon Bar-Lev <alon....@gmail.com> wrote:

Hi,

I have a very strange issue with Gerrit and a specific user.

For some reason a specific user cannot see a specific tag in a project.

The tag is not visible for a specific user in Gerrit user interface nor in `git ls-remote` output.

Other users can see the tag.

We have no specific tag access settings, the tags are quite standard... see the following, the problematic tag is v1.1.2, the rest are visible.

```

 git ls-remote | grep tags
d7aceeeb1b45396d48037ab5db07c55c24e28ce0 refs/tags/v1.0.0
c4a424ac7ae9301401bdd23a3b89f8cc9ab19a0c refs/tags/v1.0.1
f8d5a96e14d3ccf67310b262a64c9aadfe950f51 refs/tags/v1.1.0
4d8391da08d437a37a8021b31122d86cad5dda1d refs/tags/v1.1.1
70cb277cae6110a5b50833bf23717a2ad9680406 refs/tags/v1.1.2     <=====
```

The tag was created via the web user interface.

It is not an index issue as I did rebuild all indexes.

It occured on 3.12.1 and also 3.12.2.

We are using ssh protocol, but it seems unrelated as the web user interface and the git show the same result.

Any clue how to debug this?

Thanks,

Alon

--
--
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.
To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/CAOazyz0%2B2tbHDRr%2BbZAcaxqqYRz83Zo-aGmT%2B_W0f%2B5gTrW0rA%40mail.gmail.com.

[Alon Bar-Lev]

On Thu, 28 Aug 2025 at 00:14, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Wed, Aug 27, 2025 at 10:30 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hi,

I solved this by adding Read permission at  `refs/*` to Project Owners.

Now all tags are visible.

I am not sure why it should be added and what is special about this specific tag that was hidden.

Visibility on tags is determined by which branches are visible. So usually this scenario happens when these tags point to commits that are either 1) only on branches the user cannot see or 2) not on any branch (only reachable from the tag).

Hello Nasser,

Thank you for your response.

I also thought that the problem is a tag that is not reachable from any head, but this is not the case.

The user can see all the branches.

The tag is in the history of a branch.

commit 0da744e6994a737945f036a996d3408172d3f265 (origin/stable-1.1)
commit 70cb277cae6110a5b50833bf23717a2ad9680406 (tag: v1.1.2)

The interesting behavior is that I added Read permission at  `refs/*` to Project Owners and it resolved this specific tag that is missing for this user.

Thanks,

Alon

[Nasser Grainawi]

On Wed, Aug 27, 2025 at 3:30 PM Alon Bar-Lev <alon....@gmail.com> wrote:

On Thu, 28 Aug 2025 at 00:14, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Wed, Aug 27, 2025 at 10:30 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hi,

I solved this by adding Read permission at  `refs/*` to Project Owners.

Now all tags are visible.

I am not sure why it should be added and what is special about this specific tag that was hidden.

Visibility on tags is determined by which branches are visible. So usually this scenario happens when these tags point to commits that are either 1) only on branches the user cannot see or 2) not on any branch (only reachable from the tag).

Hello Nasser,

Thank you for your response.

I also thought that the problem is a tag that is not reachable from any head, but this is not the case.

The user can see all the branches.

The tag is in the history of a branch.

Hmm. Might be a bug or some other issue. Anything in the error logs? You could try using the checkAccess REST API https://gerrit-review.googlesource.com/Documentation/rest-api-projects.html#check-access

 

commit 0da744e6994a737945f036a996d3408172d3f265 (origin/stable-1.1)
commit 70cb277cae6110a5b50833bf23717a2ad9680406 (tag: v1.1.2)

The interesting behavior is that I added Read permission at  `refs/*` to Project Owners and it resolved this specific tag that is missing for this user.

That's because the default value for the config auth.skipFullRefEvaluationIfAllRefsAreVisible means READ on `refs/*` activates a special behavior that allows reading all refs.

[Vitaliy L.]

Hi

среда, 27 августа 2025 г. в 19:01:12 UTC+3, Alon Bar-Lev

We have no specific tag access settings, the tags are quite standard... see the following, the problematic tag is v1.1.2, the rest are visible.

... 

The tag was created via the web user interface.

Check if created tag lightweight or annotated, Gerrit might treat different types differently.

[Alon Bar-Lev]

On Thu, 28 Aug 2025 at 02:37, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Wed, Aug 27, 2025 at 3:30 PM Alon Bar-Lev <alon....@gmail.com> wrote:

On Thu, 28 Aug 2025 at 00:14, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Wed, Aug 27, 2025 at 10:30 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hi,

I solved this by adding Read permission at  `refs/*` to Project Owners.

Now all tags are visible.

I am not sure why it should be added and what is special about this specific tag that was hidden.

Visibility on tags is determined by which branches are visible. So usually this scenario happens when these tags point to commits that are either 1) only on branches the user cannot see or 2) not on any branch (only reachable from the tag).

Hello Nasser,

Thank you for your response.

I also thought that the problem is a tag that is not reachable from any head, but this is not the case.

The user can see all the branches.

The tag is in the history of a branch.

Hmm. Might be a bug or some other issue. Anything in the error logs? You could try using the checkAccess REST API https://gerrit-review.googlesource.com/Documentation/rest-api-projects.html#check-access

 

In the log I see:

---

[2025-08-28T06:00:22.759Z] [SSH git-upload-pack /project1 (user1)] INFO  com.google.gerrit.server.permissions.DefaultRefFilter : Performing visibility check for all refs. This can be expensive. [CONTEXT ratelimit_period="1 SECONDS" skipped=1 TRACE_ID="1756360822756-38d8c299" project="project1" request="GIT_UPLOAD" ]

---

There is no difference between the checkAccess debug_logs, however, for the v1.1.1 it is a success ("status":200) and for the v1.1.2 it is a failure with message "user 1000006 lacks permission null for refs/tags/v1.1.2 in project project1".

---

{
  "message": "user 1000006 lacks permission null for refs/tags/v1.1.2 in project project1",
  "status": 403,
  "debug_logs": [
    "\\u0027user1\\u0027 can perform \\u0027owner\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027 (allowed for group \\u002707827793233ac88881c8194cd150ed4d1927024b\\u0027 by rule \\u0027group CTO Embedded\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/version\\u0027 (allowed for group \\u0027global:Anonymous-Users\\u0027 by rule \\u0027group Anonymous Users\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/config\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/tags/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/version\\u0027 (allowed for group \\u0027global:Anonymous-Users\\u0027 by rule \\u0027group Anonymous Users\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/config\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/tags/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/version\\u0027 (allowed for group \\u0027global:Anonymous-Users\\u0027 by rule \\u0027group Anonymous Users\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/config\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/tags/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/version\\u0027 (allowed for group \\u0027global:Anonymous-Users\\u0027 by rule \\u0027group Anonymous Users\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/config\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/tags/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/version\\u0027 (allowed for group \\u0027global:Anonymous-Users\\u0027 by rule \\u0027group Anonymous Users\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/config\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/tags/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/master\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/stable-1.0\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/stable-1.1\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/notes/review\\u0027"
  ]
}

---

[Alon Bar-Lev]

Hi,

The tags are lightweight tags.

Thanks,

Alon

[Alon Bar-Lev]

Hello Nasser,

Have you reviewed the log? Have any clue what happens?

The two branch logs look identical but one fails.

Thanks,

Alon

[Björn Pedersen]

From the  docs [1]: 

• if you push a lightweight tag without the access right 'Create Reference' for the reference name refs/tags/*

• if you push a tag with somebody else as tagger and you don’t have the 'Forge Committer' access right for the reference name refs/tags/*

=> Check if the tag was created by a user without  the required permissions...

[1] https://gerrit-review.googlesource.com/Documentation/error-prohibited-by-gerrit.html

[Alon Bar-Lev]

On Thu, 4 Sept 2025 at 15:29, 'Björn Pedersen' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

From the  docs [1]: 

• if you push a lightweight tag without the access right 'Create Reference' for the reference name refs/tags/*

• if you push a tag with somebody else as tagger and you don’t have the 'Forge Committer' access right for the reference name refs/tags/*

=> Check if the tag was created by a user without  the required permissions...

[1] https://gerrit-review.googlesource.com/Documentation/error-prohibited-by-gerrit.html

Hello,

The tag was created from the UI so I do not think it could have been created without permission.

I double checked now and the default in "All-Projects" is to have "Create Reference" for "Project Owners" which the user belongs to.

This means that the user has permissions and the tag was not created by someone else.

In any case, even if we reach this situation, we should be able to query something to understand what is the current state, the checkAccess was promising but showed no reason.

Thanks,

Alon

 

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/b0780168-13fc-4bb5-bacd-c16b802298b6n%40googlegroups.com.

[Nasser Grainawi]

On Thu, Sep 4, 2025 at 2:22 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hello Nasser,

Have you reviewed the log? Have any clue what happens?

The two branch logs look identical but one fails.

Sorry, I missed replying to your earlier email. I'm confused about the "lacks permission null" part of the response message. What did your REST API request look like?

[Alon Bar-Lev]

On Thu, 4 Sept 2025 at 20:37, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Thu, Sep 4, 2025 at 2:22 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hello Nasser,

Have you reviewed the log? Have any clue what happens?

The two branch logs look identical but one fails.

Sorry, I missed replying to your earlier email. I'm confused about the "lacks permission null" part of the response message. What did your REST API request look like?

 

Hi,

Please notice that only the problematic tag produces this message.

As this is GET I just use browser, login to gerrit, then put the following in the URL:

With one of the good tags:

https://gerrit/projects/project1/check.access?account=1000006&ref=refs%2Ftags%2Fv1.1.1

{"status":200,"debug_logs":...}

With the problematic tag:

https://gerrit/projects/project1/check.access?account=1000006&ref=refs%2Ftags%2Fv1.1.2

{"message":"user 1000006 lacks permission null for refs/tags/v1.1.2 in project project1","status":403,"debug_logs":...}

The debug_logs are identical in both cases, I pasted it in the previous message.

Should I perform the call differently?

Thanks,

Alon

[Alon Bar-Lev]

On Thu, 4 Sept 2025 at 21:57, Alon Bar-Lev <alon....@gmail.com> wrote:

On Thu, 4 Sept 2025 at 20:37, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:

On Thu, Sep 4, 2025 at 2:22 AM Alon Bar-Lev <alon....@gmail.com> wrote:

Hello Nasser,

Have you reviewed the log? Have any clue what happens?

The two branch logs look identical but one fails.

Sorry, I missed replying to your earlier email. I'm confused about the "lacks permission null" part of the response message. What did your REST API request look like?

 

Hi,

Please notice that only the problematic tag produces this message.

As this is GET I just use browser, login to gerrit, then put the following in the URL:

With one of the good tags:

https://gerrit/projects/project1/check.access?account=1000006&ref=refs%2Ftags%2Fv1.1.1

{"status":200,"debug_logs":...}

With the problematic tag:

https://gerrit/projects/project1/check.access?account=1000006&ref=refs%2Ftags%2Fv1.1.2

{"message":"user 1000006 lacks permission null for refs/tags/v1.1.2 in project project1","status":403,"debug_logs":...}

The debug_logs are identical in both cases, I pasted it in the previous message.

Should I perform the call differently?

When I try to use non-existence tag, I get the same message but much shorter debug_logs it is the prefix of the debug_logs when tag exists. I guess you can test that you get this message for any non-existence tag in your environment as well.

https://gerrit/projects/project1/check.access?account=1000006&ref=refs%2Ftags%2Fv1.1.10

{
  "message": "user 1000006 lacks permission null for refs/tags/v1.1.10 in project project1",

  "status": 403,
  "debug_logs": [
    "\\u0027user1\\u0027 can perform \\u0027owner\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027 (allowed for group \\u002707827793233ac88881c8194cd150ed4d1927024b\\u0027 by rule \\u0027group CTO Embedded\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/version\\u0027 (allowed for group \\u0027global:Anonymous-Users\\u0027 by rule \\u0027group Anonymous Users\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/meta/config\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/tags/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 can perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/heads/*\\u0027 (allowed for group \\u0027global:Project-Owners\\u0027 by rule \\u0027group Project Owners\\u0027)",
    "\\u0027user1\\u0027 cannot perform \\u0027read\\u0027 with force\\u003dfalse on project \\u0027project1\\u0027 for ref \\u0027refs/*\\u0027"

  ]
}