Fuzz oracles for companion-process death and hostile host config

[ejc3]

Two defect classes surfaced while driving restores on a shared dev box (#850, #851). Each got a deterministic regression test, but the classes are broader than the instances, and the chaos fuzz can hold the line for the class.

Class 1: a companion process dies and the failure blames a downstream symptom

pasta died on a port conflict after writing its PID file and creating its TAP, so three consecutive runs failed with Cannot find device "pasta0" while pasta's own Address already in use reached no log (#851). The instance is fixed; the class is any companion (pasta, holder, UFFD serve, egress proxy) dying between a readiness signal and the next consumer of what it provides.

Proposed fuzz oracle: extend the failpoint harness with a companion-kill fault (SIGKILL one named companion at a failpoint chosen by the schedule). Invariant checked on every failed run: if a companion died, the propagated error text contains that companion's name and its last stderr line. The existing ModelBarrier-style event log can carry the "companion X died at step Y" fact; the oracle greps the run's error against it. This turns "the error blamed the wrong thing" from a human observation into a red test for every companion at every step.

Class 2: a helper binary resolves shared host config differently than podman

skopeo read /etc/containers/storage.conf literally while rootless podman remapped it, so an image podman had just built was unexportable (#850). The class is any helper (skopeo, crun, fuse-overlayfs) interpreting host-wide config differently than the tool fcvm pairs it with.

Proposed CI arm rather than fuzz: a hostile-host-config matrix leg that runs the unprivileged suite with CONTAINERS_STORAGE_CONF pointing at a conf pinning a root-only runroot, mirroring the config-managed hosts where this bit. Cheap (env var plus one file), and it would have made #850 a red CI leg instead of a field failure.

Both oracles verify diagnosability, not just correctness: a failure must carry the evidence needed to attribute it (the standing rule in AGENTS.md's CI-capture section).

[ejc3]

Triaged against main (dfd7b3b, 2026-08-18). Still valid: neither oracle exists yet.

Class 1: failpoint/src/lib.rs still has only Sleep and BlockUntilFile actions, and the chaos fuzz op table (tests/test_fuzz_chaos.rs) has no companion-kill op and no attribution oracle. The pasta instance fix from #851 (ec32c4c) added a stderr tail that failure paths consult (src/network/pasta.rs) plus the deterministic test port_conflict_failure_names_pastas_own_error, but that mechanism is pasta-only. The holder, the UFFD serve process, and the egress proxy all pipe stderr somewhere and none of them can put "which companion died and what it said" into a propagated error.

Class 2: zero references to CONTAINERS_STORAGE_CONF anywhere in the repo, and ci.yml has no hostile-config leg. The storage.conf writes in ci.yml are runner setup pointing graphroot at the btrfs mount, not the adversarial conf this issue asks for. The #850 fix (explicit driver@graphroot+runroot store in src/commands/podman/image.rs) landed untested against the config shape that bit.

Plan, in order:

1. Hostile-config CI leg (small): a job variant that sets CONTAINERS_STORAGE_CONF to a conf pinning runroot=/run/containers/storage and runs the localhost-image tests. Proof it can fail: revert the image.rs store specifier locally and the leg goes red on export exactly like the field failure in Name podman's store explicitly when exporting via skopeo #850.
2. Companion-kill fuzz op: Op::KillCompanion picks a live companion via the existing find_descendants helper, SIGKILLs it, and logs the fact in the seed's event log. Oracle: any subsequent failure in that seed must name the killed companion and its last stderr line.
3. The oracle from step 2 will fail for holder, UFFD serve, and egress proxy today, which is the point. Generalize pasta's stderr-tail into a shared companion-tail those spawn sites use, and pin each one with a deterministic kill-after-readiness test in the test_pasta_diagnostics.rs style, watched red before the plumbing lands.

Keeping this open until all three land; step 1 is a good standalone first PR.

[ejc3]

Step 1 is merged in #919 (894259c). test_localhost_export_with_root_only_configured_runroot uses a private storage configuration with a root-only runroot and runs in Host-Root CI. Removing only the explicit Skopeo store arguments reproduced EACCES; restoring them passed. Local runs passed as the unprivileged caller and through the root entrypoint, and all four Host-Root CI variants passed. No shared host configuration was changed. The companion-kill fault and attribution oracle in steps 2–3 remain open.