Indirect maintainer permissions no longer sufficient to edit (some) runner settings in the webinterface

Summary

We upgraded our selfhosted Gitlab from v17.2.8-ee to v17.3.6-ee. After the upgrade, some users can no longer edit runner settings even though they could edit them before the update and their permissions did not change.

Steps to reproduce

  • Inside one group, create one repo_a and one group_b.
  • Register project runner runner_c in repo_a.
    • For Gitlab v17.10.5-ee, the project runner ownership does not matter. The problem can be reproduced even when runner_c is owned by repo_a.
    • For Gitlab 18.1.0-pre 969a06a4 (on gitlab.com) runner_c must have been created in another project before, and user_e must not have role Maintainer in that other project (neither directly nor indirectly).
  • Invite user_d as a direct member with role Maintainer to repo_a
  • Invite user_e as a direct member with role Maintainer to groub_b.
  • Invite group_b with role Maintainer to repo_a.

user_d and user_e now both have the Maintainer role in repo_a. But user_e gained this role only indirectly through group_b (which is good, but seems to cause the bug).

What is the current bug behavior?

Indirect maintainers can no longer edit the tags, description, paused/protected/lock states of the runner.

Before the Gitlab upgrade, user_e was able to pause and edit the tags of runner_c. After the upgrade, they can still open the webinterface for editing runners¹, but when they try to click the [Save changes] button, they get below error message (even if they didn't change anything).

¹ Go to repo_a > Settings > CI/CD > Runners > runner_c #1234 > [🖊️] (Edit),
e.g. https://gitlab.intra.net/.../repo_a/-/runners/1234/edit
Then click the [Save changes] button:

The resource that you are attempting to access does not exist or you don't have permission to perform this action

Other (even higher) runner-related permissions are still working. E.g. user_e can still register new runners and delete existing runners.

For user_a nothing changed. As a direct member, they can still edit the runner just like before.

What is the expected correct behavior?

There should be no difference between direct and indirect maintainers. Both maintainers should be able to edit runners.

Please note, that according to the documentation you would require the role Owner (not Maintainer) to edit the runner ...

You can use tags to control the jobs a runner can run.

[...]

For a project runner

Prerequisites:

  • You must have the Owner role for the project.

... but this seems to be either severely outdated or simply wrong. Viewing and editing runners as a Maintainer has been working for us as long as I can remember (at least since Gitlab 15). The documentation is the same for Gitlab 16.11 too.

I expect that (both direct and indirect) Maintainers are allowed to view and edit runners (just like before the upgrade).
Furthermore, the documentation should be updated to have prerequisite Maintainer instead of Owner.

Edited by 🤖 GitLab Bot 🤖