<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=627693) </details> <!--IssueSummary end--> ### Summary A fine-grained personal access token is denied `GET /api/v4/projects/:id/pipelines/:pipeline_id/jobs` on a **public** project the token owner is not a member of, while an **anonymous** caller is allowed the same request on the same project. That breaks the parity invariant `!231701` established, and it does so because the permission the route requires, `read_pipeline_job`, is enabled by no policy rule and no role anywhere in the codebase. ### Steps to reproduce 1. Create a fine-grained personal access token with **All memberships** access and **Pipeline: Read**. 2. Pick a public project the token owner is **not** a member of, with `public_jobs: true` and `builds_access_level: enabled` — e.g. `dankparth/contributors-gitlab-com`. 3. Request that project's pipeline jobs with the token. ``` GET /api/v4/projects/dankparth%2Fcontributors-gitlab-com/pipelines/2287102464/jobs 403 {"error":"insufficient_granular_scope", "error_description":"Access denied: This operation requires a fine-grained personal access token with the following project permissions: [Pipeline: Read]."} ``` The same request unauthenticated returns **200**: ``` curl https://gitlab.com/api/v4/projects/dankparth%2Fcontributors-gitlab-com/pipelines/2294836765/jobs 200 ``` The same request with a classic `read_api` token returns **200**. ### What is expected 200, matching the anonymous caller. From `doc/development/permissions/granular_access/rest_api_implementation_guide.md`: > For `:project` and `:group` boundaries on public resources, the public-resource bypass mirrors a > non-member request: a granular PAT without scope grants access to a GET endpoint **exactly when a > legacy non-member token does** ### Root cause `Authz::BoundaryPolicy` grants a permission on either of two rules: ```ruby rule { granular_pat & cond(:"anonymous_can_#{permission}") }.enable permission rule { granular_token & cond(permission) & member }.enable permission ``` The first requires `Users::Anonymous.can?(permission, resource)`. The route requires `read_pipeline_job` (`lib/api/ci/pipelines.rb:196`): ```ruby route_setting :authorization, job_token_policies: :read_jobs, allow_public_access_for_enabled_project_features: [:repository, :builds], permissions: :read_pipeline_job, boundary_type: :project ``` `read_pipeline_job` appears in `config/authz/permissions/pipeline_job/read.yml` and in that route decorator — and **nowhere else**. It is enabled by no rule in `app/policies/project_policy.rb` or `ee/app/policies/ee/project_policy.rb`, and appears in none of the 17 files in `config/authz/roles/`, including `owner.yml` and `admin.yml`. So `Ability.allowed?(nil, :read_pipeline_job, project)` is false for every project, public or not, the bypass can never fire, and only the `member` rule is left. Its sibling `read_pipeline` **is** wired (`rule { can?(:_read_public_pipeline) }.enable :read_pipeline`) and is in `public_anonymous.yml`, so `GET /projects/:id/pipelines` succeeds where `GET /projects/:id/pipelines/:id/jobs` fails on the same project with the same token. ### Why the parity spec does not catch it The mirror assertion in the shared example is guarded: ```ruby skip 'public-access bypass only applies to public resources' unless boundary_object.public? ``` In `spec/requests/api/ci/pipelines_spec.rb` the project is `create(:project, :repository, creator: user, maintainers: user)` — **private**. The `read_pipeline_job` shared example sits inside `context 'when public_builds is true'`, which flips `public_builds` but never `visibility_level`, so `boundary_object.public?` is false and the parity check skips. ### Impact Any tool that reads pipeline jobs across projects cannot use a fine-grained token. Reviewing a merge request from a fork is the ordinary contributor workflow, and a fork's merge request runs its pipelines in the fork — so a single reviewed fork MR is enough to make the call fail, on a project that is world-readable and whose job logs are public. The error message compounds it: it names `[Pipeline: Read]`, which the token already carries, so the user re-grants a permission they already hold and the request fails again. ### Possible fixes 1. Wire `read_pipeline_job` into `ProjectPolicy` alongside `read_pipeline`, and add it to `public_anonymous.yml`, so the bypass can fire. 2. Change the route to require `read_pipeline`. I have not audited the rest of the route decorators, but the mechanism is general: any `permissions:` symbol that no policy rule enables for a nil user has the same gap, and the guarded `skip` means a private-project spec will not surface it. ### Related - !231701 — introduced the public-resource bypass - #625976 — the bypass granting more than intended, the opposite polarity of this - #599615 — follow-up questioning the `member` check itself