Repository navigation
fleet_posix_accounts: drop the host-discarding automation-user function; scope the fleet-wide claims to the hosts that hold them - #8857
Conversation
…on; scope the fleet-wide claims to the hosts that hold them fleet_automation_user_on(host) took a HostIdentity and discarded it, returning one constant. A signature promising a host-varying answer over a body that cannot give one is a false promise in the type: every call site reads `on(host:)` and believes the answer was computed for that host. Both call sites passed srv1 and srv2, which agree, so no test on the covered hosts could have exposed it. Removed rather than made to branch. The fact is genuinely uniform across the hosts this principal covers, and a constant that says so is honest where a function pretending to a variation it does not have is not. If a covered host ever differs this becomes a real per-host lookup and every call site is forced to be re-read -- which the old signature quietly prevented. Two prose claims are scoped to what was actually measured rather than left standing over a fleet that now contains counterexamples: - "Label gunbc-fleet, the same on every host" is now scoped to srv1..srv4. Measured 2026-08-22, srv5 and srv6 carry NO gunbc-fleet account; they run gunbc-automation, a separately declared principal (operator declaration 2026-08-12 in gunbc.spark.serving_desired) with disjoint permitted operations. The unscoped sentence is the stale-citation mechanism: a reader looking for the automation account on srv5 finds nothing and concludes the host is unprovisioned. - automation_uid_coincidence_note recorded two accounts reading uid 1001. A third does: gunbc-automation on srv5 and srv6. The hazard it named got worse rather than different -- a reader treating uid as identity now fuses three principals, one with disjoint sudo grants from the other two. fleet_account_contradiction_dissolve_on gains evidence only, and deliberately does not correct the authored ghrunner values: `getent passwd ghrunner` returns nothing on srv5 or srv6, so the row is wrong there in a second way. Hand-editing observed numbers in would satisfy the letter of the condition while bypassing the ProcessReceipt grounding the condition exists to require. It also narrows what a corrected row must say: uid/gid alone cannot express an account that does not exist on a host. No behavior change. The symbol had zero references outside its own module. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The failing check on this PR is inherited from main, not caused hereRun 32545830237 @ I diffed the failure identities against main's own witnesses run at The two sets are identical. All 16 are Main's history: last green
So there is nothing to fix here, and I am not pushing a commit. A change made to turn this check green would be a change with no defect behind it. This PR is unblocked the moment main is. — sent from fierce-lynx-647 |
1 participant
What
fleet_automation_user_on(host: HostIdentity)took a host and discarded it, returning one constant. Replaced withdata fleet_automation_user: PosixUser; both call sites updated. Two fleet-wide prose claims scoped to the hosts that actually hold them, and one dissolve-on row gains evidence.Why the signature was the defect
A signature promising a host-varying answer over a body that cannot give one is a false promise in the type. Every call site reads
on(host:)and believes the answer was computed for that host. Both call sites passedsrv1andsrv2— which agree — so no test over the covered hosts could ever have exposed it.Removed rather than made to branch: the fact is uniform across the hosts this principal covers, and a constant that says so is honest where a function pretending to a variation it does not have is not. If a covered host ever differs, this becomes a real per-host lookup and every call site is forced to be re-read — exactly what the old signature quietly prevented.
The scoping fixes
Measured against the live fleet on 2026-08-22:
gunbc-fleetaccount; they rungunbc-automation, a separately declared principal with disjoint permitted operationsautomation_uid_coincidence_note: two accounts read uid 1001gunbc-automationis 1001:1001 on srv5 and srv6fleet_posix_ci_runner_usercarries contradicted uid/gidgetent passwd ghrunnerreturns nothing on srv5 or srv6 — absent, not merely differentThe unscoped sentence is the stale-citation mechanism from DESIGN.md §3: a reader looking for the automation account on srv5 finds nothing and concludes the host is unprovisioned, rather than that they read a claim whose scope narrowed underneath it.
What this deliberately does NOT do
fleet_account_contradiction_dissolve_ongains evidence only. The authored ghrunner values are left wrong. Hand-editing the observed numbers in would satisfy the letter of the dissolution condition while bypassing theProcessReceiptgrounding the condition exists to require — the precise failure mode it was written against. The new evidence also narrows what a corrected row must say: uid/gid alone cannot express an account that does not exist on a host, so grounding has to carry per-host presence rather than one fleet-wide pair.Verification
0 blocking error(s)on the module..dagand.rscorpus-wide), so this is not a behavior change.getent,sudo -l).