Enrolment code: memory-bounded scope for the verb; ntfy auth-file is the observed auth.db

[gunbai-bot]

Two defects found on release 02568b3 (broker listening), reported by proud-deer-538.

1. No cgroup memory bound

• Symptom: fleet-converge run 36556990543 refused HostBudgetUnreadable. The seed derives its typed-module cache cap from memory.high/memory.max and refuses rather than guess, and an SSH session binds neither.
• Fix: gunbc.auth.approval_device_enrolment_code_issue enrolment_code_issue_remote_argv now runs:
  sudo -n systemd-run --scope --uid=<operator> --gid=<operator> --property=MemoryMax=… --property=MemoryHigh=… -- /usr/bin/env GUNBC_WORKSPACE_ROOT=<release> <release gunbc> run …
• Why a system scope: it is a system-manager scope that runs the verb as the operator's account. A --user scope needs that account's session bus, which the sudo -u command lacks.
• Helper: new extdeps.systemd.systemd_run systemd_run_scope_as_account_argv, beside the existing user-scope form, reusing its property rendering.
• Bounds: from gunbc.live_deploy.slice_bounds approval_broker_slice_memory_max / _high, not literals. The verb resolves the broker's own routes closure, so the broker's measured demand bounds it. It gets its own scope; joining the broker's slice would split one budget between the running broker and this run.
• Elevation: the bootstrap principal holds (ALL) NOPASSWD: ALL, so root elevation for systemd-run is already covered.

2. ntfy auth file

• Symptom: the readback stat'd /var/lib/gunbc-ntfy/user.db, but srv1's running server.yml names auth.db (which exists; user.db doesn't).
• Fix: gunbc.auth.approval_ntfy_deployment approval_ntfy_auth_file_path is corrected to the observed file.
• Why it stays a declaration, not a value read from the config: the stat runs through sudo -n at an exact argv that an operator-installed sudoers line must name, and a path chosen at runtime could only be granted by a pattern. The readback refuses unless the running config names exactly this path, so the config is checked, not trusted.
• Operator step: srv1's sudoers line for that stat must be re-issued naming auth.db; the operator instructions rendered from this row update with it. Fixtures follow; the other.db RED is unchanged.

Witness: the_remote_argv_runs_the_release_verb_as_the_operator_user pins the whole prefix: root sudo, the scope as the operator, both bounds built from the slice rows, the env binding, then the release binary.

Not evaluated locally. One unverified bet: that srv1's systemd applies --uid/--gid to a --scope child. My reading of systemd-run(1) and run.c says it does; the wet check is the next enrolment dispatch at the merged sha.

🤖 Generated with Claude Code

[gunbai-bot]

Corrections to the description, from proud-deer-538's reads on srv1 (2026-09-29):

• --uid on a scope is verified: sudo -n systemd-run --scope --uid=briansrls --gid=briansrls -p MemoryMax=1G -- id -un prints briansrls, so the one unverified bet in the description holds.
• No operator action is needed for the auth-file stat. srv1 has no sudoers line naming it (sudoers.d holds only the broker-helpers grant), and the stat of auth.db succeeds under the operator account's own broader sudo. The earlier refusal was the missing user.db, not a grant.
• A gap to note, not a blocker: the model's human step asks for a narrow exact-argv grant for that stat, and srv1 has broader access than that. e9a415f rewrites the row's note to say so instead of asserting that a grant must be re-issued.

— sent from fierce-deer-555