Admin users cannot read all refs/changes/*.

[everni...@hotmail.com]

Hi all. We are using Gerrit 2.13.14. Since a few days ago, several users have reported that they failed to run "git fetch <url> refs/changes/xx/xxxxx/1" and it said "fatal: couldn't find remote ref refs/changes/xx/xxxxx/1". We also find that even the admin user cannot fetch the ref.

The users still have access to the change page. They can fetch the target branch and manipulate the commit. After checking the access configuration of all levels, we didn't find any ref pattern related with "refs/changes/*". The only possible pattern is "refs/*". But to my knowledge, it should affect all refs. Now in the same repository, a user can fetch some of its "refs/changes/*" and cannot fetch the others.

Taking one of the repositories for example, "git for-each-ref refs/changes" in the server repository prints 19503 refs, but `git ls-remote | refs/changes" in the client repository prints only 4342 refs. We compared the 2 groups of refs and found that roughly the refs whose 4th part(the legacy number) is smaller than a certain number cannot be fetched. We couldn't find out the specific boundary number but it's around 3050000. "refs/changes/10/3049710/1" cannot be fetched but "refs/changes/10/3059210/1" can. And there are several exceptions. 2877409 is smaller than 3050000 but "refs/changes/09/2877409/1" can be fetched.

So far we have tried explicitly granting the access "read refs/changes/*" or "read refs/changes/10/3049710/1" with and without exclusive to the admin user. But the admin user cannot fetch "refs/changes/10/3049710/1".

Thanks for any suggestion and help.

 

[Luca Milanesio]

On 25 Apr 2021, at 07:43, everni...@hotmail.com <everni...@hotmail.com> wrote:

Hi all. We are using Gerrit 2.13.14.

Are you aware that you are running a largely unsupported release?

See the project support policy at [1].

You should upgrade to:

1. Upgrade to v2.16 / ReviewDb

2. Convert your ReviewDb to NoteDb

3. Upgrade to at least v3.1

Your version became EOL over 2 years ago !

Since a few days ago, several users have reported that they failed to run "git fetch <url> refs/changes/xx/xxxxx/1" and it said "fatal: couldn't find remote ref refs/changes/xx/xxxxx/1". We also find that even the admin user cannot fetch the ref.

I would check for any change in the project (or its parent projects) ACLs.

Also, I would check in staging if a reindex would make those refs visible again.

Gerrit checks for the changes’ status during ACL evaluation, but if there are issues with the indexes, then you may have some refs becoming invisible.

HTH

Luca.

The users still have access to the change page. They can fetch the target branch and manipulate the commit. After checking the access configuration of all levels, we didn't find any ref pattern related with "refs/changes/*". The only possible pattern is "refs/*". But to my knowledge, it should affect all refs. Now in the same repository, a user can fetch some of its "refs/changes/*" and cannot fetch the others.

Taking one of the repositories for example, "git for-each-ref refs/changes" in the server repository prints 19503 refs, but `git ls-remote | refs/changes" in the client repository prints only 4342 refs. We compared the 2 groups of refs and found that roughly the refs whose 4th part(the legacy number) is smaller than a certain number cannot be fetched. We couldn't find out the specific boundary number but it's around 3050000. "refs/changes/10/3049710/1" cannot be fetched but "refs/changes/10/3059210/1" can. And there are several exceptions. 2877409 is smaller than 3050000 but "refs/changes/09/2877409/1" can be fetched.

So far we have tried explicitly granting the access "read refs/changes/*" or "read refs/changes/10/3049710/1" with and without exclusive to the admin user. But the admin user cannot fetch "refs/changes/10/3049710/1".

Thanks for any suggestion and help.

 

--
--
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 on the web visit https://groups.google.com/d/msgid/repo-discuss/9100803b-7f0e-4437-aa52-ac6b6d578eb0n%40googlegroups.com.

[Luca Milanesio]

On 25 Apr 2021, at 15:37, Luca Milanesio <luca.mi...@gmail.com> wrote:

On 25 Apr 2021, at 07:43, everni...@hotmail.com <everni...@hotmail.com> wrote:

Hi all. We are using Gerrit 2.13.14.

Are you aware that you are running a largely unsupported release?

See the project support policy at [1].

The Support policy:

[1] https://www.gerritcodereview.com/support.html

You should upgrade to:

1. Upgrade to v2.16 / ReviewDb

2. Convert your ReviewDb to NoteDb

3. Upgrade to at least v3.1

The upgrade path you should follow:

https://www.youtube.com/watch?v=uAUw1hHiVC4

Luca.

[everni...@hotmail.com]

Thanks for your suggestions, Luca. It's quite old. But just like we still have to run python 2.7 on some of our machines, we can't upgrade this gerrit instance now.

We tried reindex and it didn't solve the problem. To my experience, it works for invisible changes created when Gerrit is being restarted. And for those previous invisible changes, none of the users have access to the change pages. Now we can browse the page, but can't fetch its pending change ref.

As to the ACLs, we couldn't find out which kind of ref patterns would affect only some of the "refs/changes". Maybe we need to replicate the gerrit instance and revert recent ACL changes one by one.

[Matthias Sohn]

On Mon, Apr 26, 2021 at 3:27 AM everni...@hotmail.com <everni...@hotmail.com> wrote:

Thanks for your suggestions, Luca. It's quite old. But just like we still have to run python 2.7 on some of our machines, we can't upgrade this gerrit instance now.

How is that connected ? Gerrit is a Java application ...

 

We tried reindex and it didn't solve the problem. To my experience, it works for invisible changes created when Gerrit is being restarted. And for those previous invisible changes, none of the users have access to the change pages. Now we can browse the page, but can't fetch its pending change ref.

As to the ACLs, we couldn't find out which kind of ref patterns would affect only some of the "refs/changes". Maybe we need to replicate the gerrit instance and revert recent ACL changes one by one.

Read access to changes depends on having read permission on the target branch of a change in review.

If there is an open change in review for the master branch you need read access to the master branch 

in order to have read access to this change [1].

 

Watch out for READ, DENY and BLOCK rules in the permission settings of the respective project and its parent projects.

[1] https://gerrit-documentation.storage.googleapis.com/Documentation/2.13.13/access-control.html#category_read

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/dcf3442f-af92-496d-8425-2bbb5bd650a5n%40googlegroups.com.

[everni...@hotmail.com]

Thanks, Matthias. Forget about my nonsense on python.

The users can read changes (I mean browse the change pages) and fetch the target branch, but can't fetch its "refs/changes" refs.