Repository navigation
T66 — Spawn gvproxy and the VMM child through sudo -n as their dedicated users #2566
Description
Task
| slice | size | difficulty | model | who | estimated lines |
|---|---|---|---|---|---|
| Proxy as the operator, VM as its own user | L | unknown ground | strongest | an agent | 720 (420 code, 300 tests) |
Where the vm-users drop-in is installed, gvproxy runs as
minimal-gvproxyand the VMM child asminimal-vmm, each spawned throughsudo -nunder the drop-in, with their files invmm/and the gvproxy dirs at the T57 design's modes; where it is not, both run as the login user andmin finalize-installnames why.
Covers:
- BEP-047
Layers:
- spawn:
- crates/minvmd/src/cmd/run.rs: spawns gvproxy and the VMM child through
sudo -n -uunder the drop-in, each in a new process group, never sending SIGKILL to thatsudo; movesssh.sock,timekeep.sock,boot.loganddata-vol.rawintovmm/, the switch socket to<gvproxy dir>, andgvproxy.yamlandgvproxy-bep.sockto<gvproxy config dir>; verifies the modes ofvmm/boot.logandvmm/data-vol.raw; refuses to start when the drop-in is installed andsudo -nfails; when the drop-in is not installed (the binaries sit under a path the login user can write, or the dedicated users cannot reach the provider dir), spawns gvproxy and the VMM child as the login user with today's layout (split from T65 on 2026-10-25 by the epic owner; arch C1 on feat(minimal): lay out the split VM users, directories and socket modes (T65) #2561; owner ruling on gominimal/arch#143, 2026-10-26) - crates/minvmd/src/net.rs:
HostGvproxy::spawnstarts gvproxy throughsudo -n -u minimal-gvproxy, andGvproxyConfig::with_config_pathwritesgvproxy.yamlat 0640 groupminimal-gvproxy - crates/minvmd/src/cmd/vmm_child.rs: takes the gate socket path from
<gate dir>, reads its per-run values on descriptor 0, and sets the mode ofssh.sockafter libkrun binds it - crates/minvmd/src/vm.rs: reads the per-run values the VMM child receives on descriptor 0 in place of the environment
- crates/minvmd/src/image.rs: reads the image paths from those per-run values in place of the environment
- crates/minvmd/src/telemetry.rs: reads the telemetry setting from those per-run values in place of the environment
- crates/minvmd/src/cmd/stop.rs: stops a VMM child that runs as another user through the
__stop-groupstop rule in place of signallingvmm_pid - crates/minvmd/src/main.rs: the hidden
__stop-groupsubcommand, and__krun-vmmtakes the literal argument the drop-in names - crates/minimal-client/src/attach.rs:
minfinds the ssh socket atvmm/ssh.sock - crates/minimal/src/cmd/finalize_install.rs: offers the vm-users item again, moves an existing
data-vol.rawintovmm/as root, and installs the drop-in whose rules match the spawns as minvmd defines them; on a host that cannot meet Gatehouse §6.10 line 831 the item stays not possible and names the reason, which is where the user sees that the split users are not set up (gominimal/arch#143) cargo nextest run -p minvmd gvproxy_and_vmm_run_as_their_dedicated_userscargo nextest run -p minvmd without_the_drop_in_gvproxy_and_vmm_run_as_the_login_user
- crates/minvmd/src/cmd/run.rs: spawns gvproxy and the VMM child through
Waits on:
Plan block
### T66 — Spawn gvproxy and the VMM child through sudo -n as their dedicated users
slice: S8
kind: task
covers: BEP-047
size: L
est: 420 code, 300 tests
executor: agent
difficulty: unknown ground
model: strongest
diagnostics: when the vm-users drop-in is installed and `minimal-vmm` or `minimal-gvproxy` is missing, or `sudo -n` cannot run a spawn, the VM host daemon refuses to start with the error the T57 design's ownership model names, on stderr; on a host without the drop-in, the VM runs as the login user and `min finalize-install` shows the vm-users item as not possible, with the reason
observability: one info log line at start naming the user gvproxy and the VMM child run as, the login user included
layers:
- spawn:
- crates/minvmd/src/cmd/run.rs: spawns gvproxy and the VMM child through `sudo -n -u` under the drop-in, each in a new process group, never sending SIGKILL to that `sudo`; moves `ssh.sock`, `timekeep.sock`, `boot.log` and `data-vol.raw` into `vmm/`, the switch socket to `<gvproxy dir>`, and `gvproxy.yaml` and `gvproxy-bep.sock` to `<gvproxy config dir>`; verifies the modes of `vmm/boot.log` and `vmm/data-vol.raw`; refuses to start when the drop-in is installed and `sudo -n` fails; when the drop-in is not installed (the binaries sit under a path the login user can write, or the dedicated users cannot reach the provider dir), spawns gvproxy and the VMM child as the login user with today's layout (split from T65 on 2026-10-25 by the epic owner; arch C1 on #2561; owner ruling on gominimal/arch#143, 2026-10-26)
- crates/minvmd/src/net.rs: `HostGvproxy::spawn` starts gvproxy through `sudo -n -u minimal-gvproxy`, and `GvproxyConfig::with_config_path` writes `gvproxy.yaml` at 0640 group `minimal-gvproxy`
- crates/minvmd/src/cmd/vmm_child.rs: takes the gate socket path from `<gate dir>`, reads its per-run values on descriptor 0, and sets the mode of `ssh.sock` after libkrun binds it
- crates/minvmd/src/vm.rs: reads the per-run values the VMM child receives on descriptor 0 in place of the environment
- crates/minvmd/src/image.rs: reads the image paths from those per-run values in place of the environment
- crates/minvmd/src/telemetry.rs: reads the telemetry setting from those per-run values in place of the environment
- crates/minvmd/src/cmd/stop.rs: stops a VMM child that runs as another user through the `__stop-group` stop rule in place of signalling `vmm_pid`
- crates/minvmd/src/main.rs: the hidden `__stop-group` subcommand, and `__krun-vmm` takes the literal argument the drop-in names
- crates/minimal-client/src/attach.rs: `min` finds the ssh socket at `vmm/ssh.sock`
- crates/minimal/src/cmd/finalize_install.rs: offers the vm-users item again, moves an existing `data-vol.raw` into `vmm/` as root, and installs the drop-in whose rules match the spawns as minvmd defines them; on a host that cannot meet Gatehouse §6.10 line 831 the item stays not possible and names the reason, which is where the user sees that the split users are not set up (gominimal/arch#143)
test: cargo nextest run -p minvmd gvproxy_and_vmm_run_as_their_dedicated_users
test: cargo nextest run -p minvmd without_the_drop_in_gvproxy_and_vmm_run_as_the_login_user
produces: none
consumes: none
proof: Where the vm-users drop-in is installed, gvproxy runs as `minimal-gvproxy` and the VMM child as `minimal-vmm`, each spawned through `sudo -n` under the drop-in, with their files in `vmm/` and the gvproxy dirs at the T57 design's modes; where it is not, both run as the login user and `min finalize-install` names why.
depends on:
- blocked by T65
Generated by Claude Code
Reacted by minimal-foundry
Activity
norrietaylor commentedon Oct 25, 2026
Held by the epic owner on 2026-10-25 until arch rules on gominimal/arch#143. The sudoers drop-in this task installs must name root-owned binaries, but the default install puts
minvmdand gvproxy in$HOME/.local/bin, and a 0700 home blocks the dedicated users from the provider dir. The ruling decides where the binaries and the provider dir live, which changes this task's layers. Split from T65 (#2560) per arch C1 on #2561.Generated by Claude Code
fix(minimal): guard each cd -P by inode, hold back vm-users (T65)
norrietaylor commentedon Oct 26, 2026
Amended on 2026-10-26 after the epic owner's ruling on gominimal/arch#143 (https://github.com/gominimal/arch/issues/143#issuecomment-6409882754): a host that cannot meet Gatehouse §6.10 line 831 runs the VM as the login user, and says so.
run.rs: spawns throughsudo -nonly where the vm-users drop-in is installed, and refuses to start when it is installed andsudo -nfails. Where it is not installed, gvproxy and the VMM child run as the login user with today's layout.finalize_install.rs: on such a host the vm-users item stays not possible and names the reason. That is the surface where the user sees that the split users are not set up. Nothing prints before the box shell.cargo nextest run -p minvmd without_the_drop_in_gvproxy_and_vmm_run_as_the_login_user.The hold is lifted, and the plan comment carries the same text.
Generated by Claude Code
minimal-foundry commentedon Oct 26, 2026
**The coder changed nothing: noop: the task cannot be done inside its layers. Every layer path exists at the branch head, and T65 (be9202e) has landed. The problem is a missing piece of the design, not a wrong path.
The split layout in the T57 design (docs/design/2026-10-25-split-user-vmm-provider-dir.md, 'Ownership model' and 'What T38 changes') depends on the EGW process. The EGW process is a
minvmd __egwprocess that runs as minimal-gvproxy. It holds the egress gate and the switch::bep_host leg. No task layer creates it, and the tree does not have it:rg -n '__egw|egw' crates/minvmd/srcfinds only comments in sock.rs. The egress gate still runs in the supervisor as the login user (crates/minvmd/src/net.rs, theEgressGate::spawn(shuttle::gate_sock_beside(&sock), sock.clone(), ...)call near line 840).Under the layout the task asks for, that supervisor gate cannot work, for two reasons:
branch
agent/2566-spawn-gvproxy-and-the-vmm-child-through-sudo-n-a· epic #1501Updated 2026-10-26T07:19:57.553Z.
feat(minimal): lay out the split VM users, directories and socket mod…
norrietaylor commentedon Oct 31, 2026
Deferred on 2026-10-31 by the owner in the #1501 close-out. This task leaves slice S8 (#2256) and the #1501 plan. The split-user work moves to the follow-on epic gominimal/inbox#1184, with BEP-047, which spec 24 moves to Non-goals in #2768. This issue stays open for that epic to take.