Repository navigation
capability: Load: read status of the current thread - #273
Merged
Merged
Conversation
Capabilities (including ambient ones) are per-thread, and capget(2) with pid of 0, as well as Apply, operate on the calling thread. Yet, Load reads ambient and bounding sets from /proc/self/status, which describes the thread group leader (the main thread). As a result, if Load is called from a thread other than the main one (e.g. a goroutine which did runtime.LockOSThread), it returns ambient and bounding sets of the main thread, not the current one. This is the cause of occasional TestAmbientCapSet failures in CI: capability_test.go:171: Get(AMBIENT, kill): want true, got false Fix this by reading /proc/thread-self/status, with fallbacks to /proc/self/task/<tid>/status (for pre-3.17 kernels) and /proc/self/status (when our pid namespace differs from that of /proc), similar to what mountinfo does. Also, lock the OS thread in Load so that capget and the status file refer to the same thread. To make the test failure deterministic rather than occasional, lock the main goroutine of a test helper process to the main thread, so that tests never run on it. Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
kolyshkin
force-pushed
the
cap-thread-self
branch
from
October 26, 2026 21:28
9339f5a to
a8ebe60
Compare
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues were identified for the calling-thread capability loading fix.
No open issues 🎉
What changed in this PR
Fixes capability loading so ambient and bounding sets reflect the calling thread rather than the main thread.
Changes:
- Reads the current thread’s status with fallbacks for older kernels and PID namespace mismatches.
- Locks the OS thread during current-thread loading to keep capability reads consistent.
- Makes the test setup reliably exercise non-main threads and documents the fix.
| File | Description |
|---|---|
capability/CHANGELOG.md |
Documents the current-thread capability loading fix. |
capability/capability_test.go |
Pins the helper process’s main goroutine so tests run on other threads. |
capability/capability_linux.go |
Adds thread-specific status lookup, fallbacks, and OS-thread locking during loading. |
Review effort: Balanced
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Capabilities (including ambient ones) are per-thread, and capget(2) with pid of 0, as well as Apply, operate on the calling thread. Yet, Load reads ambient and bounding sets from
/proc/self/status, which describes the thread group leader (the main thread).As a result, if Load is called from a thread other than the main one (e.g. a goroutine which did
runtime.LockOSThread), it returns ambient and bounding sets of the main thread, not the current one. This is the cause of occasionalTestAmbientCapSetfailures in CI (e.g. https://github.com/moby/sys/actions/runs/40385946276/job/121794105561):Fix this by reading
/proc/thread-self/status, with fallbacks to/proc/self/task/<tid>/status(for pre-3.17 kernels) and/proc/self/status(when our pid namespace differs from that of/proc), similar to what mountinfo does. Also, lock the OS thread in Load so that capget and the status file refer to the same thread.To make the test failure deterministic rather than occasional, lock the main goroutine of a test helper process to the main thread, so that tests never run on it. With this test change but without the fix,
TestAmbientCapSetfails 20 out of 20 runs; with the fix, it passes.