---
id: "bug-1934"
status: "fixed"
status_updated: "2026-10-10"
status_note: ""
component: "apiserver"
severity: "security"
timestamp: "2026-10-10T04:31:25Z"
last_seen: "2026-10-10T04:31:25Z"
occurrences: 1
files: ["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"]
tags: ["apiserver", "rbac", "security", "self_ug"]
related: ["bug-1935"]
fix_commits: ["4a38bb3c"]
gitea_issue: 359
gitea_synced_status: "fixed"
gitea_synced_hash: "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`:
```go
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()`)