The capability-hint test asserted the environment, not the code — main is red on a machine where nothing is wrong #139

Merged

enricobuehler merged 1 commits from worktree-kwin-capability-test-env into main 2026-08-09 09:10:36 +00:00

Conversation 0 Commits 1 Files Changed 1

+35 -2

enricobuehler commented 2026-08-09 08:40:02 +00:00

Owner

Copy Link

Copy Source

silent_without_capabilities (added in #136) calls the real capability_denial_hint() and asserts it returns "", on the strength of its own doc comment:

The test process has no capabilities.

True on a dev box. False in CI, where the runner container is root with a full permitted set. main went red on 0f79587d:

left: " — NOTE: this process carries capabilities (CapPrm=0x000001ffffffffff) …"
right: ""

Nothing was actually wrong. The hint fired correctly, on a process that really did hold every capability. The test was reading the ambient environment and calling it a property of the code.

The fix finishes a split that was already half-done

permitted_caps_from_status had been split out for precisely this reason — its own comment says "split out from capability_denial_hint purely so that shape is testable without a capability-carrying process to point at" — but only the parse half. The message half still went to /proc/self/status.

Now:

• capability_denial_hint_for(Option<u64>) — the formatting, takes the mask
• capability_denial_hint() — reads /proc/self/status, delegates

Both keep their callers (the three error paths still use the latter), so neither becomes dead code — which this release has already been bitten by once, in #134.

And a counterfactual, because the silent case alone proves nothing

names_the_mask_and_the_repair_when_capped asserts the capped path actually speaks, naming the mask and setcap -r. Without it, silent_without_capabilities passes just as well against a function that returns "" unconditionally — the exact shape of un-failable test this repo has been burned by before.

⚠ Verification

CI is the proof. kwin.rs is #[cfg(target_os = "linux")] and does not compile on the macOS host this was written from. cargo fmt --all --check is clean. I did try a Linux container check, but the stock rust image has no cmake, so audiopus_sys fails its build script long before the test runs.

The difference worth noting: unlike the test it replaces, this one now passes or fails for reasons that have nothing to do with the machine running it.

Does not touch the release

v0.26.0 is unaffected — ci.yml triggers on push: branches: [main] and pull_request only, never on tags, and no tag leg runs cargo test. This is main-hygiene, not a release blocker.

`silent_without_capabilities` (added in #136) calls the real `capability_denial_hint()` and asserts it returns `""`, on the strength of its own doc comment: > The test process has no capabilities. True on a dev box. **False in CI**, where the runner container is root with a full permitted set. main went red on `0f79587d`: ``` left: " — NOTE: this process carries capabilities (CapPrm=0x000001ffffffffff) …" right: "" ``` Nothing was actually wrong. The hint fired **correctly**, on a process that really did hold every capability. The test was reading the ambient environment and calling it a property of the code. ## The fix finishes a split that was already half-done `permitted_caps_from_status` had been split out for precisely this reason — its own comment says *"split out from `capability_denial_hint` purely so that shape is testable without a capability-carrying process to point at"* — but only the **parse** half. The **message** half still went to `/proc/self/status`. Now: - `capability_denial_hint_for(Option<u64>)` — the formatting, takes the mask - `capability_denial_hint()` — reads `/proc/self/status`, delegates Both keep their callers (the three error paths still use the latter), so neither becomes dead code — which this release has already been bitten by once, in #134. ## And a counterfactual, because the silent case alone proves nothing `names_the_mask_and_the_repair_when_capped` asserts the capped path actually speaks, naming the mask and `setcap -r`. Without it, `silent_without_capabilities` passes just as well against a function that returns `""` unconditionally — the exact shape of un-failable test this repo has been burned by before. ## ⚠ Verification **CI is the proof.** `kwin.rs` is `#[cfg(target_os = "linux")]` and does not compile on the macOS host this was written from. `cargo fmt --all --check` is clean. I did try a Linux container check, but the stock `rust` image has no `cmake`, so `audiopus_sys` fails its build script long before the test runs. The difference worth noting: unlike the test it replaces, this one now passes or fails for reasons that have nothing to do with the machine running it. ## Does not touch the release `v0.26.0` is unaffected — `ci.yml` triggers on `push: branches: [main]` and `pull_request` only, never on tags, and no tag leg runs `cargo test`. This is main-hygiene, not a release blocker.

enricobuehler added 1 commit 2026-08-09 08:40:02 +00:00

fix(pf-vdisplay): the capability-hint test asserted the environment, not the code ... e8a4f54c07

`silent_without_capabilities` called the real `capability_denial_hint()` and
asserted it returns "", on the strength of a doc comment that read "The test
process has no capabilities."

That is true on a dev box and false in CI, where the runner container is root
with a full permitted set. main went red on 0f79587d with:

    left: " — NOTE: this process carries capabilities (CapPrm=0x000001ffffffffff) …"
   right: ""

Nothing was wrong: the hint fired correctly, on a process that really did hold
every capability. The test was reading the ambient environment and calling it a
property of the code.

`permitted_caps_from_status` had already been split out for exactly this reason
— "so that shape is testable without a capability-carrying process to point at"
— but only the PARSE half. The message half still went to /proc/self/status.
This finishes the split: `capability_denial_hint_for(Option<u64>)` holds the
formatting and takes the mask, `capability_denial_hint()` reads /proc and
delegates. Both keep their callers, so neither is dead code.

Also adds `names_the_mask_and_the_repair_when_capped`. Without it the silent
case passes just as well against a function that returns "" unconditionally —
which is the failure mode this repo has been bitten by before, and the reason
every decode fix carries a counterfactual.

No behaviour change: the three error paths call the same function and get the
same string.

⚠ Verification is CI. `kwin.rs` is `#[cfg(target_os = "linux")]`, so it does not
compile on the macOS host this was written from; `cargo fmt --all --check` is
clean and a Linux container check was attempted but the stock rust image has no
cmake for audiopus_sys, so it never reached the test. ci.yml going green on main
is the proof — and unlike the case it replaces, this test now fails or passes
for reasons that have nothing to do with the machine running it.

Does not touch the v0.26.0 tag: ci.yml runs on `push: branches: [main]` and
`pull_request` only, and no tag leg runs cargo test.

enricobuehler merged commit 3cfa5ca194 into main 2026-08-09 09:10:36 +00:00

enricobuehler deleted branch worktree-kwin-capability-test-env 2026-08-09 09:10:38 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

FernandoMX enricobuehler (Enrico Bühler) kszlim nannku neoney sassycrown

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unom/punktfunk#139