One argv grounds both the command and its grant: privileged operations stop being binary paths

[briansrls]

srv3's converge apply refused at its first privileged command with zero slots mutated. The cause was two authorities answering one question.

The roster granted binary paths (install, rm, systemctl, apt-get, visudo, tailscale) while extdeps.github.actions_runner independently rebuilt an argv from those paths. Nothing joined them — so a grant for /usr/bin/install did not imply authorization for the argv the script actually ran. The disagreement was discoverable only by a wet apply on a real host.

The construction

gunbc.executor_privileged_operation declares the operation once — parameterized, not a nullary enum of binaries — and derives both renderings from one argv projection:

projection	value	role
executor_privileged_operation_argv	the words	the source
..._sudoers_command	join(argv, " ")	what authorizes
..._shell_command	sudo + quoted argv	what executes

A grant that fails to authorize its own command now has no spelling. Quoting is shell-level and invisible to sudo — which receives argv after the shell has parsed it — so one argv grounds both renderings without either knowing the other's escaping.

Deleted, not accumulated beside

ActionsRunnerPrivilegedBinaries and gunbc_runner_privileged_binaries() are gone. extdeps no longer rebuilds argv at all; it splices commands it is handed and stays agnostic. Net removal of a parallel rendering, per §2 dissolution-on-climb.

Two narrowings (from the antagonist review)

• run_as is now root, not ALL. ALL=(ALL) authorized the grantee to run the command as any user, including other service accounts.
• No wildcard reaches the rendered file. /opt/actions-runner/* matches .. — fnmatch's * declines to cross /, and .. contains none — so it would authorize rm -rf /opt/actions-runner/... Every managed path is named in full.

Two modules, structurally

gunbc.runner_host_grants joins the operation authority to a host's slot roster. An operation module that also read the roster would close an import cycle with runner_slot_provision, and acyclicity is the one structural law the import graph has.

A §3 residual, with a trigger

The fleet-converge state directory was spelled three times in fleet_converge_plan and named nowhere: once as a bare literal in the lease guard, twice more as the leading segment of the generation store and lock paths. This declares it once; the row dissolves when fleet_converge_plan derives all three from it.

Evidence

Six witnesses, green by execution, RED measured rather than asserted.

The load-bearing one is witness_executed_command_is_the_granted_command: it reaches the command the provisioning script runs through runner_slot_provision's real seam, and the command the sudoers file grants through the renderer, and asserts they are one word vector.

Mutation receipt: dropping the quoting from the shell projection returns false; restoring returns true.

Note: this branch carries #9097's commit as its base (that PR's parameter route is what this replaces). If #9097 lands first this rebases cleanly; if this lands first, #9097 becomes unnecessary.

🤖 Generated with Claude Code

[gunbai-bot]

Both findings verified and fixed in 826ad81.

Finding 2 — the static break — was real and worse than reported. fleet_converge_plan_witness_test did call the deleted gunbc_runner_privileged_binaries and did still pass the removed job_user. I missed it because I ran my own witness file and the slot-provision ones, but not this one — the deletion's census was exactly the thing I failed to run.

Beyond what the review names: that witness's assertions also spelled the sudo commands as unquoted string literals (sudo /usr/bin/install -d -m 755 -o ghrunner ...). Against the posix-quoted rendering this PR introduces, those would have gone permanently red. They are now built from the authority (executor_privileged_operation_shell_command) rather than restated — which is the same drift this PR exists to remove, so a literal there would have reintroduced it one layer out. Verified green by execution.

Finding 1 — the hand-written shell — is also correct, and it is out. A raw shell observation step with no .dag carrier and no dissolution trigger is the §6 out-of-band-actuation tell, and it was a separate concern from the model change besides. The workflow file is now byte-identical to origin/main. The capability is preserved on session/warm-tern-755-grants-observe and will land with a .dag authority instead of as workflow shell.

Worth recording why that observation matters and why it has not run: every claim about srv3's grant state still rests on one observed refusal — a single argv under /usr/bin/install — and I generalized it earlier into statements about six binaries. It is measurable read-only via sudo -n -l, I dispatched it, and it has been sitting queued behind 15 in-progress runs. The runner shortage is currently blocking the diagnosis of the runner shortage.

— sent from warm-tern-755

[gunbai-bot]

Both findings verified and acted on in 36bdb5f.

Finding 2 — the wrong entry point — was real, and it was the second time that string has been wrong. It named executor_privileged_operation.dag until the module split moved the renderer (review 55626), and then named srv3's entry point for every host once srv1 and srv4 started rendering through the same function — so srv1's installed sudoers file told a reader to reproduce it with srv3's command, on a production host, in the one string a human reads while deciding whether a generated file is safe to regenerate.

It now takes a parameter rather than a constant, because a constant cannot be right: the reproducing entry point is a fact about the host, not about the renderer. Verified by execution — srv1, srv3 and srv4 each name their own.

Finding 1 — the unwired planner — is also correct, and I removed it from this PR rather than wire it.

The reason it cannot get a consumer here is a measurement, not an omission: gunbc.fleet_converge_plan observes nothing about build-cache or compile-pool readiness — zero matches for BuildCacheInstanceReady, HostCompilePoolReady, or admit_runner_activation anywhere in that module. The activation admission's inputs are receipts that path does not produce.

That left two ways to wire it into slot_apply_lines, and both are worse than splitting. Fabricating the readiness receipts so the gate opens is the fabricated-plausible-output failure. Emitting a gate that can never open makes activation strictly worse than today, where a human starts the units and knows they did.

The model, its 13-row truth table and its mutation receipt are preserved on session/warm-tern-755-runner-activation and will land with the observation layer that feeds the admission. That is a family — observe enabled/active per slot, mint the readiness receipts, then a reviewed activation plan with its own subject and fresh observations — not a line appended to the install script.

Not claimed as fixed: apply.sh still emits only daemon-reload and disable, so convergence still calls a host converged when its slots serve no traffic. That failure mode is open, and this PR does not close it.

For context on what this PR did deliver: the grant/argv unification is live on three hosts, and the runner bump took the fleet from 10 serving runners to 39 (srv1 5→21, srv3 5→18). The deprecated 2.334.0 pin — not privilege — was the actual capacity blocker.

— sent from warm-tern-755

[gunbai-bot]

Fixed in a2d25b3aa5 — the marker was genuinely missing and now binds to gunbc.host_effect host_effect_apply, the same dissolution target this module's sibling scaffold already uses. They dissolve together or not at all: once host_effect_apply owns the actuation, neither this renderer nor the extract script needs to spell a program.

One correction to the framing, which does not change the verdict. "Introduces a hand-built shell program" overstates what the diff did to the string surface: extdeps.github.actions_runner on main already carries three inline join(["sudo ", ...]) concatenations, already under actions_runner_slot_extract_script_scaffold, and this PR replaced them with one derived rendering. The debt predates the diff and the diff reduces its authorings from three to one.

So the gate fired correctly on a population that got smaller, not larger — what was missing was the marker on the new home. I mention it only because a future reader comparing the finding to the diff would otherwise look for a string surface this PR created, and there isn't one.

Join witness re-run green.

Separately, for anyone triaging CI here: main's last three completed runs all fail with NonVerdictRowUnreachable count=127, so red on branches that have merged main is inherited rather than caused by them.

— sent from warm-tern-755

[gunbai-bot]

Checked this one against the tree and it does not hold — the witness exists and executes.

dag/test/claim/executor_privileged_operation_witness_test.dag:80:

test fn witness_bootstrap_principal_is_not_the_grantee() -> Bool {
  bootstrap_principal_is_not_the_grantee(
    bootstrap: srv3_executor_bootstrap_principal,
    deploy: srv3_runner_host_deploy,
  )
}

It landed with the predicate in the same commit (ff4f01b, Encode the bootstrap principal), not separately.

Rather than just assert that, here is the execution receipt for the stronger claim — that the wall discriminates rather than being permanently green. Mutation: point srv3_executor_bootstrap_principal.login at the deploy row's job_user (ubuntu → ghrunner), which is precisely the self-authorizing account the law forbids:

tree	result
bootstrap == grantee	false
restored	true

So it is not prose with a function shape: an edit that makes the grantee its own bootstrap principal fails here. Working tree is clean — the mutation was reverted.

I want to flag why this is worth more than a correction, because the finding names a real class I have been caught by twice on this PR. Both times the fix was to remove the unwired thing, so "authored but unconsumed" was the right prior to apply here. It just happens to be wrong on this specific symbol, and the way to tell the difference is execution rather than git grep — a symbol can be referenced from a witness in the same commit that introduces it, which is what happened.

No change pushed for this item.

— sent from warm-tern-755