test: fail when sudo action filter selects nothing

[ITSMERNB]

Summary

• count sudo action specs that survive both catalogue filters
• fail if the guard is no longer looking at a meaningful set of actions
• keep the threshold as a floor so adding new sudo actions does not create churn

Validation

• sudo -> sudoz mutation: targeted nextest run started 2 tests and failed with only 0 sudo action specs were checked
• restored filter: targeted nextest run started 2 tests and passed 2/2
• cargo fmt --all -- --check
• git diff --check

Closes #408

[vladimirrott]

Reviewed at 27d05215714cfddf250ec3ce6e5b06d9afbf907b.

Six lines, and they close a hole I would not have found by reading. I proved both directions in a network-isolated container rather than reasoning about it.

With your change, breaking the filter so it selects nothing:

$ sed -i 's/if \*program != "sudo" {/if *program != "sudoX" {/' crates/sysknife-daemon/tests/sudoers_grants_match_argv.rs
$ cargo test -p sysknife-daemon --test sudoers_grants_match_argv --offline
running 2 tests
test every_sudo_action_is_authorised_by_a_packaged_grant ... FAILED
panicked at crates/sysknife-daemon/tests/sudoers_grants_match_argv.rs:116:5:
only 0 sudo action specs were checked; the mechanism or program filter must have changed and this guard is no longer looking at anything
test result: FAILED. 1 passed; 1 failed

The same mutation against main, without your six lines:

$ git checkout origin/main -- crates/sysknife-daemon/tests/sudoers_grants_match_argv.rs
$ sed -i 's/if \*program != "sudo" {/if *program != "sudoX" {/' ...
$ cargo test -p sysknife-daemon --test sudoers_grants_match_argv --offline
running 2 tests
test every_sudo_action_is_authorised_by_a_packaged_grant ... ok
test result: ok. 2 passed; 0 failed

Green, checking nothing, for as long as anyone cared to look. That is the whole argument for this PR and it is now on the record. The guard that verifies every sudo action has a matching grant could have been silently inspecting an empty set after any refactor of ActionMechanism, and the board would have stayed green.

I like that you put the counter next to the pre-existing assert!(!grants.is_empty(), ...). Both inputs to the cross-check are now guarded, which makes the pair read as deliberate rather than as one-off paranoia.

One optional note, with a measurement attached. I set the threshold impossibly high to make the test print the real number:

$ sed -i 's/checked > 50,/checked > 100000,/' ...
only 132 sudo action specs were checked; ...

So the live count is 132 against a floor of 50. The guard fires only if the catalogue loses more than 61% of its sudo specs. That still catches the failure you wrote it for, which is the filter going vacuous, so I am not asking you to change it. If you want it tighter, something near 120 would catch a partial regression too, at the cost of a number that needs nudging when the catalogue grows. Your call, and it does not block the merge.

Heads up on a collision that is not your fault: #429 edits the same function at the same insertion point, so whichever of the two lands second needs a trivial rebase. Both additions are compatible and the resolution is to keep both lines. I will handle the ordering.

Approving. This is a small diff that makes an existing guard honest, which is my favourite kind.

[vladimirrott]

Merged as 026880a.

You turned a guard that could pass while looking at nothing into one that says so out loud, and the gate ran that proof rather than taking my review's word for it:

$ maintainer-merge verify 421 986f65bfef044723418d97843d8bf06298f8284f 'every_sudo_action_is_authorised_by_a_packaged_grant' 's/if \*program != "sudo" {/if *program != "sudoX" {/' rust
  rust suite: evidence of 1 executed unit(s), passing unmutated
  applying the mutation and re-running
  receipt recorded for #421 at 986f65bf (observed: clean pass, mutated fail)

The mutation breaks the program filter so the loop selects nothing, which is the exact shape your assertion exists for, and it fails at rc=101:

test every_sudo_action_is_authorised_by_a_packaged_grant ... FAILED

I updated your branch against main first, because #426 landed in between. That update was mechanical and moved nothing of yours:

$ git merge-tree --write-tree main 27d05215
4164a938a4bf76e4c5aca71236c685a6279993de
$ git rev-parse 986f65bf^{tree}
4164a938a4bf76e4c5aca71236c685a6279993de

I said on the review that the #429 ordering was mine to handle, and it is: #429 now conflicts in your file, in CHANGELOG.md and in docs/action-reference.md. That is my merge order, not anything either of you did, and I am telling @QinXi-ai the same thing on that thread.

#423 is still waiting on the .githooks finding, and #409 and #408 are yours already, so I am not adding anything to your queue.

Two pull requests from you in a week, both about making a check able to fail, says you have been burned by one that could not. If you run Linux anywhere that matters, a server you patch or a fleet you keep alive, I would like to know how SysKnife reads there. npx sysknife-setup gets it running, and the read-only side (sysknife doctor, sysknife history, sysknife audit verify) changes nothing on the host.