<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=602977) </details> <!--IssueSummary end--> <!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary <!-- Summarize the bug encountered concisely. --> In gitlabs job token permissions, less specific rules can take precedence over more specific rules. The job token permissions in settings > CI/CD > Job token permissions, seem to be in cascading order of precedence, where the lower down permission rules are preferred over higher up rules. However the repositories own rules are always pinned to the top, with no ability to override the order. Thus giving any other repository any fine-grained permissions to a higher level group that may contain this repository overrides the repositories own job permissions as a consequence of this ordering. So take for instance a top level group called `acme`, if they had two repositories at any level of depth under this group which we will say are: - `acme/a/foo` - `acme/b/bar` If repository `foo` has a container registry of images used in `bar`s CI pipeline. For instance if repository `foo` is a [CI component repository](https://docs.gitlab.com/ci/components/). Then giving any permissions to `bar` from `foo`s job token permissions will cause `foo` to lose its native permissions, which means it loses its ability to do any action that is not subsequently provided to other repositories. Things like pulling its own artifacts in multi-stage ci pipelines, or writing to its own container registry etc. ### Steps to reproduce <!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. --> - Stage 1 (setup): You will need two repositories (`foo`, `bar`) under the same top level group (`acme`), where at-least the providing repository `foo` is private. You will need the `foo` repository to provide something to the other `bar` repository, the easiest being container images for the CI. You will note that repository `bar`s pipelines will fail initially as it will not have permission to access the container under the `foo` repository. This is expected, as at this point the job token permissions should look something like this: {width=900 height=173} - Stage 2 (problem): We add job token permissions to repository `foo` to say that any repository under `acme` should be able to read our `foo` artifacts as part of its CI pipeline using `bar`s job token. You will then see that upon adding permissions to `foo` for `bar`, `foo` will lose its own permissions to do things like publish container images, fetch multi-step artifacts etc. At this point the permissions should look something like this: {width=900 height=220} - Stage 3 (workaround): At this point your only choice unless you want to enumerate and keep a list of sub-groups up to date, is to give `foo` back its permissions in a lower-down higher priority permission. However you cannot specify only the `foo` repository since it is already pinned to the top. This is not ideal for multiple reasons, since you are effectively giving every repository under `acme/a` full permission to do anything to `acme/a/foo` as long as the one who triggered the pipeline could do so. This could lead to all sorts of issues or accidents. {width=900 height=270} ### Example Project <!-- If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report. If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version. --> This can only be reproduced in a private repository. In public repositories things like their container registries can naturally be read by anything, thus I would not be able to show the loss in permissions since even if the repositories own permissions are reduced it would still be able to pull the public images. ### What is the current *bug* behavior? <!-- Describe what actually happens. --> In stage 2, adding permissions for other repositories overrides the repositories own permissions in its own CI. ### What is the expected *correct* behavior? <!-- Describe what you should see instead. --> Adding permissions for other repositories (`bar`) should not override more specific permissions for our own repository (`foo`). Or at-least we should be able to re-order the permissions to manually specify what should override what. ### Relevant logs and/or screenshots <!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise. --> Screenshot of one possible `bar` that cannot pull from `foo` without stage 2: {width=900 height=92} Screenshot of one possible `foo` that cannot publish its own packages to its own package registry due to permissions being overriden by stage 2: {width=900 height=177} ### Output of checks <!-- If you are reporting a bug on GitLab.com, uncomment below --> This bug happens on GitLab.com <!-- and uncomment below if you have /label privileges --> <!-- /label ~"reproduced on GitLab.com" --> <!-- or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not --> #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->