docs(buglog): log P0 defects from the 2026-10-10 review (bug-1936..bug-1952)

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

2026-10-10 08:15:28 +00:00

2.2 KiB

Raw Blame History

status

status_updated

status_note

component

severity

timestamp

last_seen

occurrences

files

bug-1952: apiserver user role changes check a narrower rbac:control grant only against the target user

Description

Observed: (source reading, .kiro/reviews/project-gap-review-2026-10-10.md (P0); to be confirmed by a failing test before the fix) Suspected (needs verification): in add/delete roles for a user, a non-all rbac:control grant is only checked against "is the target me?" (controllers/users.go:404-412,455-462), so such a grant could let a user give itself cluster_admin. Built-in roles grant rbac:control only with domain all (config/rbac.yaml:100-102), so this is latent.

Expected: A user can never grant itself a role with more rights than it already holds. Impact: Security (latent): privilege escalation through a custom role. Found by: review: .kiro/reviews/project-gap-review-2026-10-10.md (P0)

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)
Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
Build: asan (xce.build)
Code: scheduler-framework @ 94472ee3-dirty
Deployment: any (found by source reading; the failing test that confirms it is named in Verification)

Reproduction

Define a role with rbac:control scoped to self, assign it to a user, then add cluster_admin to that same user via the users API.

Frequency: deterministic (by code reading; confirmed by the RED test of the fix)
Evidence: the code sites quoted in Description; no logs kept.

Root cause

TODO: required for fixed/partial

Fix