fix(ociruntime): check CAP_SYS_PTRACE on first use, not at package initialization

[achoimet]

Why

ociruntime decides once, when the package is initialized, whether CAP_SYS_PTRACE is in the effective set (var isCapSysPtraceSet = hasCap(unix.CAP_SYS_PTRACE)). Without it, every namespace lookup falls back to spawning a root readlink process and logs "CAP_SYS_PTRACE capability is not set. Using fallback with reduced performance."

extension-container and extension-host are moving their file capabilities from setcap …+eip to +ip, so that a missing capability no longer makes exec fail (the extension crash-loops today). Their capabilities then only become effective in main() (extruntime.RaiseCapabilities), after package initialization, and this check always sees them missing: every attack would take the slow path, with a false warning.

Seen in the E2E logs of steadybit/extension-container#525: the warning appears 7 times in the PR run vs once on main.

What

Evaluate the check on first use (sync.OnceValue), which happens when an attack runs, after main() has raised the capabilities. Nothing changes for binaries that keep the effective bit.

Related

• feat(extruntime): raise capabilities at startup and report missing ones extension-kit#181 — RaiseCapabilities
• feat: start without all capabilities and fail fast for the actions needing a missing one extension-container#525, feat: start without all capabilities and fail fast for the actions needing a missing one extension-host#264 — setcap +ip, they will depend on this fix

[claude]

Claude finished @achoimet's task in 27s —— View job

---

Claude's Review

• Gather context (PR body, diff, changed file)
• Check for previously unresolved Claude review threads (none found — no prior review threads exist on this PR)
• Review new changes
• Post final review

Summary

The change moves the CAP_SYS_PTRACE check from package-init time to first-use time via sync.OnceValue, which correctly addresses the described race: extensions using setcap +ip only raise capabilities to effective in main(), after package vars are initialized, so the old eager check always saw the capability as missing.

Correctness / concurrency: sync.OnceValue guarantees hasCap runs exactly once, the result is cached, and concurrent callers are safely synchronized — no race condition introduced. The call site (isCapSysPtraceSet() in executeReadlinkInProc) is updated correctly to invoke the function.

Security: No implications — this only affects the performance fallback path for capability detection logging, not the capability itself.

No bugs, security, or performance issues found. This is a small, well-targeted fix; the added comment clearly explains the non-obvious motivation (why init-time evaluation was wrong).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud