| 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 |
|
|
|
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
- 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.
- As
alice: xcecli jobs list -u bob (or -u all), or
GET /api/v1/jobs?filters={submit_user:eq:bob}.
- 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())