spec(ENV-LEASE-GPU-CAPABILITY): the missing capability is CAP_SYS_ADMIN, and it is absent from the worker's BOUNDING set

[localai-bot]

spec(ENV-LEASE-GPU-CAPABILITY): the missing capability is CAP_SYS_ADMIN, and it is absent from the worker's BOUNDING set

#1354 records that
nvidia-smi -lgc returns LGC_RC=4 inside an rc lease as root, and its
option 1 asks for the capability to be named so the fleet owner receives a patch
rather than a symptom. Both halves of that identification are now closed. This
is records only: no src/, include/, tests/ or tools/ file changes, and
git diff $(git merge-base origin/main HEAD)..HEAD -- tools/ src/ include/ tests/
is empty.

The driver side, now pinned

lease-clock-pinning.md §Evidence records its CAP_SYS_ADMIN quotation as "an
external reference nobody here has read at a pinned revision" and names what
confirming it owes: "either a checkout at a named revision or a link to the exact
blob". This pays that, at tag 580.173.02 — the driver version the refusing dgx
job reported at job.log:9.

grep -n 'capable(\|CAP_' over kernel-open/common/inc/nv-linux.h and
kernel-open/nvidia/os-interface.c at that tag returns four hits and no others,
so the open kernel module's whole Linux privilege surface is three tests:

Test	Blob and line	Reached by
capable(CAP_SYS_ADMIN)	nv-linux.h:537	NV_IS_SUSER(), and through it os_is_administrator()
capable(CAP_PERFMON)	os-interface.c:390	os_check_access(RS_ACCESS_PERFMON)
capable(CAP_SYS_NICE)	os-interface.c:397	os_check_access(RS_ACCESS_NICE)

os_check_access closes default: { return NV_FALSE; }, so a right that is
neither PERFMON nor NICE is refused outright rather than falling through to
the administrator test. That bounds the candidate set at three and leaves
CAP_SYS_ADMIN as the test a privileged clock control reaches.

What this does not establish, stated rather than buried. NVML and
nvidia-smi are closed source, so that nvmlDeviceSetGpuLockedClocks calls
os_is_administrator rather than os_check_access is an inference from the
enumeration, not a read of the call site. The enumeration is what makes it
tight, and the acceptance test below discriminates all three.

The container side, now measured

It was never measured; it was derived from manifests. Two rc run probes on the
idle thor:gpu0 (job 34e3fb43) and orin:gpu0 (job dd72fa7b), both as
uid=0(root), read byte-identical masks:

CapPrm: 00000000a80425fb
CapEff: 00000000a80425fb
CapBnd: 00000000a80425fb

  CAP_SYS_ADMIN    Eff=no Prm=no Bnd=no
  CAP_PERFMON      Eff=no Prm=no Bnd=no
  CAP_SYS_NICE     Eff=no Prm=no Bnd=no

0x00000000a80425fb is the default 14-capability OCI set. CapBnd is the
load-bearing column: a capability absent from the bounding set cannot be
regained by setcap, by a setuid binary, by NoNewPrivs being 0, or by
re-execing. So no job-side workaround exists, and this is container
configuration rather than job authorship. NoNewPrivs: 0 and Seccomp: 0 in
the same read rule out a seccomp filter as an alternative explanation.

thor:gpu0 reproduced the refusal itself on driver 595.78, so it is measured
on two boxes and two driver versions rather than one, and the manifest-derived
fleet-wide claim becomes a measurement.

Three readings ruled out by reading rather than assuming: every NVML query in
the same job succeeded (READ_RC=0), so NVIDIA_DRIVER_CAPABILITIES is not it;
/dev/nvidiactl is present and world-writable, so the device cgroup is not it;
and /proc/driver/nvidia/params reads RmProfilingAdminOnly: 1, which governs
profiling counters and is a different gate, so nobody should reach for an
NVreg knob expecting -lgc to start working.

The ask, and the test that falsifies it

One line on the worker container in infra-flux-kube
manifests/{dgx,thor,orin}/rc-worker.yaml:

        - name: worker
          securityContext:
            capabilities:
              add: ["SYS_ADMIN"]

rc run -d dgx:gpu0 -- bash -c 'nvidia-smi -lgc 2100; echo LGC_RC=$?; nvidia-smi -rgc'

LGC_RC=0 and the diagnosis was right. LGC_RC=4 still and the control does not
reach os_is_administrator, so try add: ["PERFMON"] next — not
privileged: true, whose success would name nothing and which grants every
capability, disables seccomp and AppArmor and relaxes the device cgroup. If the
fleet owner wants least privilege first, PERFMON is the cheaper probe and the
same test discriminates it. The cost is stated plainly in the spec: the grant
reaches every job submitted through rc, not only the worker.

No threshold moves, deliberately

MAX_WITHIN_RUN_SPREAD_PCT stays 5.0, BENIGN_THROTTLE_MASK stays
0x1 | 0x2 | 0x100, and no constant in tools/bench/gpu_clock_state.py is
touched. A capability diagnosis is not evidence about a statistic, and #1354
refuses a widening that turns a red green. The rule question of option 3 is
already argued on evidence in lease-clock-pinning.md half two and
clock-gate-route.md §Is it a forbidden widening; this row adds nothing to it
and needs nothing from it.

Two things this does not do

It recovers no ratio. The nine 2026-08-19 windows carry an independent
throttle refusal that no grant removes from archived data, exactly as
clock-gate-route.md §What no route recovers states.

It did not attempt #1354's settle-and-hold option, and the spec says why
rather than proposing an unvalidated procedure. dgx:gpu0 — the only GB10 and
the only box the 5% failure was measured on — was held by BENCH-QWEN38-27B-SOTA
for the whole session with a live server container on it; rc hold is not this
row's to take; and thor:gpu0 and orin:gpu0 report [N/A] for the SM clock
the 5% rule bounds, so the quantity is not readable there. A procedure could not
have been demonstrated, and naming one that was not run is what the issue
forbids.

Records

environment.md and benchmarking.md also gain the 2026-08-21 finding from
#1574 that pinning works from
the leased HOST at 0.29% spread under a ten-minute decode load, together with the
part that keeps #1354 open: that path needs a campaign-scoped rc hold plus
ssh authorization which developer-preferences.md explicitly leaves unchanged
for every other row, so the pod path is still the only path for every other row
and is still refused. Its two caveats travel with it — persistence mode can be
lost when the last GPU client detaches, so verify the clock DURING the run; and
the recorded -lgc 2100 recipe is about 69% of this device's 3003 MHz maximum,
right for a RATIO and wrong for an ABSOLUTE.

No .agents/issue-index.md row is appended: #1354 is already indexed at row 446
and this row opens no new issue.

Gates

• scripts/check-commit-style.py --range origin/main..HEAD — OK: commit writing style, rc 0
• scripts/check-commit-trailers.py --range origin/main..HEAD — OK: commit trailer contract, rc 0
• scripts/agent-preflight.sh — every Record gate ok, including check-env-doc, check-now-current, check-symbol-anchors, audit-live-rows and check-agent-record
• git diff $(git merge-base origin/main HEAD)..HEAD -- tools/ src/ include/ tests/ — empty, which is this row's central claim

Owed

dgx:gpu0's own capability mask. The same sixty-second probe is queued behind
BENCH-QWEN38-27B-SOTA and had not run at the time of writing, so dgx's mask is
inferred from two agreeing devices and the manifests while its refusal is
measured three times on 2026-08-19. Listed under ## Owed in the spec.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]