myxce/.wolf/bugs/bug-1934.md

7.7 KiB

id status status_updated status_note component severity timestamp last_seen occurrences files tags related fix_commits gitea_issue gitea_synced_status gitea_synced_hash
bug-1934 fixed 2026-10-10 apiserver security 2026-10-10T04:31:25Z 2026-10-10T04:31:25Z 1
src/frontend/apiserver/controllers/jobs.go
src/frontend/apiserver/controllers/rbac_check.go
src/frontend/apiserver/models/roles.go
src/frontend/apiserver/config/rbac.yaml
apiserver
rbac
security
self_ug
bug-1935
4a38bb3c
359 fixed c1449c52b0d4

bug-1934: apiserver treats a job:view grant scoped only to self_ug as all: user sees every user's jobs

Description

Observed: (source reading, not yet run) a role whose job:view grant is scoped only to self_ug can see every user's jobs. The job-list handler (src/frontend/apiserver/controllers/jobs.go) only distinguishes DomainType == self:

if permission.DomainType != models.DomainTypeSelf {
    submitUser = filter.Value            // jobs.go:178, caller-chosen user
}
...
if !specify_user || permission.DomainType == models.DomainTypeSelf {   // :187
...
if jobPermission.DomainType == models.DomainTypeSelf {   // :762, per-row owner filter

so self_ug falls through every check like all: a submit_user filter naming any user (or all) is honoured and no row is removed. GetRequireResourcePermission() (controllers/rbac_check.go:323-346) returns only the first grant matching the permission, so for the default basic_user (config/rbac.yaml:37-40, job:view with self then self_ug) the self entry wins and self_ug is silently ignored. self_ug is accepted by role validation (controllers/roles.go:697-700) and listed as a supported job scope (models/roles.go:70), but nothing resolves the user's user groups for it.

Expected: a self_ug job grant covers exactly the jobs whose owner shares a user group with the requester; a grant list with several scopes covers the union of them; anything else is rejected or filtered out. Impact: security (authorization bypass). Any role an admin creates with job:view (or another job permission, unchecked) scoped to self_ug grants visibility of all users' jobs. The default basic_user is not exposed (its self grant is matched first) but never gets the group visibility its config promises. Other job permissions using the same single-grant lookup were not checked yet. Found by: review, during /kiro-spec-requirements project-config (2026-10-10, RBAC survey for project-scoped job permissions). UPDATE (2026-10-10): confirmed by the new tests in src/frontend/apiserver/controllers/job_scope_test.go against the unfixed handlers: with only self_ug grants, alice listed carol's job (submit_user carol: rows [..907], want []), read it by ID (200), and killed it (Job control <kill> accepted, dispatched). job:control is affected as well as job:view. A user holding self and self_ug together got self only (the second scope was dropped).

Environment

  • OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
  • libc: glibc 2.42-47 (interpreter /nix/store/wb6rhpznjfczwlwx23zmdrrw74bayxw4-glibc-2.42-47/lib/ld-linux-x86-64.so.2), from src/xce.build/frontend/apiserver/xce_apiserver
  • Toolchain: go1.25.5 linux/amd64 (nix dev shell); gcc (GCC) 15.2.0, meson 1.9.1
  • Build: asan (xce.build) binary exists at this commit; the bug was found by reading the source, not by running it
  • Code: scheduler-framework @ 54c8b29e
  • Deployment: any apiserver deployment (single or HA); not reproduced on a running cluster yet

Reproduction

  1. Start an apiserver with a role ug_viewer granting job:view with only - type: self_ug, plus queue:view on all, assigned to user alice; submit a job as user bob.
  2. As alice: xcecli jobs list -u bob (or -u all), or GET /api/v1/jobs?filters={submit_user:eq:bob}.
  3. Expected: rejected or empty (unless alice and bob share a user group); per the source reading, bob's job is returned.
  • Frequency: deterministic by code reading; not yet executed.
  • Evidence: the code lines quoted in Description; no logs.

Root cause

Three defects in src/frontend/apiserver:

  • Every job-permission check read one scope: GetRequireResourcePermission() (controllers/rbac_check.go) returns the first grant of the permission, and DeduplicatePermissions() keeps one entry per permission name, so a self + self_ug grant became one scope.
  • The checks compared that scope only with self (controllers/jobs.go job list ~178/187, by-ID ~762, both control paths ~2190 and ~2457; output.go compared with all), so any other scope, self_ug included, fell through as unrestricted in the list, by-ID and control paths.
  • The apiserver had no user-group data: handleConfigPush() (backend/clib.go) ignored cluster_config_t.ugroups, so self_ug could not have been resolved anyway. Also in the by-ID path: rows were removed from the slice being ranged over, which skipped the row after each removal. Since: pre-existing; self_ug was added as a job scope without enforcement (origin not bisected).

Fix

  • controllers/job_scope.go (new): userJobScope() collects every grant of a job permission before deduplication (collectUserPermissionsWithType(), split out of GetUserAllPermissionsWithType() in rbac_check.go) and adds them up: all covers every job, self the user's own, self_ug the user and everyone sharing a user group with them; other scope types cover nothing. covers(owner) and ownerFilter() (a submit_user in/notin condition for job queries) apply it.
  • controllers/jobs.go: the job list appends the owner filter for narrower scopes (a submit_user the scope does not cover now yields no rows); the by-ID path keeps covered rows in a new slice and answers 403 (was 500) when nothing is visible; both control paths reject an uncovered job with 403. controllers/output.go: the owner may always read; others need a covering job:view grant.
  • store/usergroups.go (new) holds the user groups and resolves membership (users, nested groups, all, exclusions, cycle-safe); models/usergroups.go (new) the model; backend: cClusterConfUserGroups() converts cluster_config_t.ugroups, and handleConfigPush() calls the new NotificationHandler.OnUserGroupsUpdated(), which replaces the store.
  • Behaviour change: the default basic_user (job:view with self and self_ug) now also sees the jobs of users sharing a user group with them, as its configuration says; before, it saw only its own.

Verification

  • Test: src/frontend/apiserver/controllers/job_scope_test.go: TestJobScope_SelfUGListCoversGroupOnly, TestJobScope_SelfUGGetByID, TestJobScope_SelfUGControl, TestJobScope_SelfUGOutput, TestJobScope_GrantsAddUp: all RED before the fix (carol's job listed, read, killed; group mates' output refused; self+self_ug collapsed to self), GREEN after. store/usergroups_test.go TestUserGroups_Membership and backend/handler_test.go TestOnUserGroupsUpdated_ReplacesUserGroups (new code; RED as undefined symbols before).
  • Suites: xce-build.sh apiserver asan xce.build --incremental: apiserver Go packages (store, utils, controllers, backend, backend/auth) and all xcecli packages ok; cgo xce_apiserver built; meson apiserver suite 1/1 OK; 2026-10-10.
  • Live: n/a: handler-level tests drive the real gin handlers, RBAC loading and stores; the only untested seam is the cgo conversion of cluster_config_t.ugroups, which compiled into xce_apiserver; not run against a live controller.

References

  • Related: bug-1935 (same session, same files)
  • Spec: .kiro/specs/project-config/requirements.md Requirement 8 (project job scope builds on userJobScope())