test(security): the token-squat guard asserts nothing under root and prints ok — CI containers commonly run as root

[MichaelTaylor3d]

Task

foreign_owned_token_file_is_regenerated_not_trusted asserts NOTHING when run as root, and prints
ok. crates/dig-node-service/src/control.rs:4329.

Every assertion sits inside if !running_as_root { … }. Under root the test creates the fixture, calls
load_or_create_token_at, checks nothing, cleans up, and reports success.

Why this one matters more than an ordinary skipped test

It guards a token-squat attack, in its own words:

a pre-existing control-token file that is NOT owned by a trusted principal … MUST be DELETED and
REGENERATED — never returned — so a planted/squatted token can never become the trusted one (which
would hand an attacker full local node control).

And CI containers commonly run as root. So this may have been reporting ok without ever exercising
the guard — on the one test standing between a planted token and full local node control. Determine
whether the CI leg that runs it is root; if it is, this guard has never fired and its ok is
meaningless.

A silently-skipping test is worse than a missing one: a missing test is visible in coverage and in a
reviewer's head, while this one reads as a passing security guard.

The fix, which the sibling crate already demonstrates

Assert the complementary observable in the root branch rather than skipping. dig-keystore hit exactly
this pattern and fixed it that way (PR #17) — under root, mode is legitimately not the discriminator,
but something is still true and assertable.

Here the root branch should assert what root-owned actually implies: that a root-owned file IS
legitimately trusted and is therefore returned as-is — the stated reason for the carve-out. That turns
the branch into a real second case rather than a hole, and it would catch a regression that started
regenerating trusted tokens.

Do not simply #[ignore] it under root. An ignored test is at least honest, but it leaves the root
path — the one CI actually takes — unguarded.

Scope

crates/dig-node-service/src/control.rs. dig-node has live lanes (a #3128 producer lane and a
#2790 NC-12 lane) — work in your own worktree off origin/main, one cargo process at a time, never
the shared checkout.

Grep for the same shape while you are here. Any if !running_as_root { …asserts… },
if uid != 0 { … }, or silent early-return inside a #[cfg(unix)] security test has this defect.

Evidence

• Prove the negative first: run the test as root with the guard deliberately broken (return the
  planted token) and show it still passes. That is the defect, and it is what the fix must change.
• Then show the fixed test failing under root against that same broken guard.
• Read passed-counts, never ok — and note this ticket is precisely a case where ok meant nothing.
• Any mutation asserts its patch applied; parse the test result: line, never stderr.

Provenance

The pattern was identified by the dig-keystore lane on eco#1502, which found it in its own suite and
suggested an ecosystem grep. That grep found this instance. The dig-keystore occurrence is already
fixed in its PR #17; this one is not.

Release hazard: dig-node's cron cuts a stable tag at midnight UTC unattended, so main reaches
real users without a human. The merge gate is the last line of defence.

[MichaelTaylor3d]

Owned by the key-custody/pairing/authz batch lane.

• branch: loop/batch-seckey (worktree dn-seckey, based on origin/main 3e480dd)
• draft PR: fix(security): gate the wallet transport and make the no-mint rule structural #452 (closes this ticket)

Progress will be logged here at each increment.

[MichaelTaylor3d]

Fix landed on loop/batch-seckey (PR #452)

The ticket's diagnosis is confirmed and the fix is a real second case, not a skip.

Under root, unix_token_owner_is_trusted(0, mode, _) returns true for ANY mode — so the MODE
genuinely is not the discriminator and asserting the mode case would be wrong. But OWNERSHIP still
is, and only root can hand a file to another uid. That is what the root branch now does:

• foreign_owned_token_file_is_regenerated_not_trusted — the root branch asserts the carve-out
  itself (a root-owned 0644 token IS kept as-is), then chowns a second fixture to uid 65534,
  asserts the chown actually took (metadata().uid() == FOREIGN_UID — without it the branch
  proves nothing), and asserts that token is REGENERATED. Deleting the trust check fails this
  branch, whichever uid runs it.
• unreadable_token_maps_to_permission_denied_not_not_found — root reads through mode 000, so
  PermissionDenied is unreachable. The root branch now asserts the complementary observable: the
  token IS returned, and in particular the classifier does not invent the misleading NotFound for
  a plainly-present file.
• token_file_is_trusted_accepts_0600_rejects_group_readable (state.rs:1482) — the same shape,
  found by the sweep the ticket asked for. Same treatment.
• the_unix_token_trust_rule_refuses_a_foreign_owner_at_every_mode — NEW, and the one that is
  privilege-independent. unix_token_owner_is_trusted is pure, so it is interrogated for the
  foreign-owner case on a root runner and the root case on an unprivileged one, across four modes,
  including the case a filesystem test cannot reach: a foreign-owned token must not become trusted
  merely because WE are root. A filesystem test only ever sees the cases its runner's privileges
  permit; this one sees all of them.

Sweep result: three instances of the shape ecosystem-wide in this repo — the two named in the
ticket plus state.rs:1482. grep for if !running_as_root, if uid != 0 returns nothing else.

I ALSO reintroduced the shape while fixing #345 and caught it. The natural fixture for "a
present but unreadable file" is chmod 000, which is exactly a guard that stops discriminating
under root. #345's test uses a directory at the file path instead — Present to try_exists,
unreadable to fs::read, on every platform and at every privilege level.

HONEST VERIFICATION GAP, stated rather than glossed. This host is Windows, so none of the
#[cfg(unix)] tests above executed locally — not the fixed branches and not the new pure-rule
test. I attempted a --target x86_64-unknown-linux-gnu type-check to at least prove they compile;
it failed in a vendored OpenSSL build (perl missing Locale::Maketext::Simple), unrelated to this
change. CI's Linux leg is the first thing that runs them, and per the ticket that leg is
plausibly root — which is now the branch that asserts rather than the branch that skips. I have NOT
run the ticket's suggested "break the guard, run as root, watch it still pass" demonstration.

SPEC.md §18.25d states the rule: a privilege-gated test MUST assert in every privilege branch.