f74de9beb8
Four findings from review, all of them real. The relay's directory was mounted on the tree a session's shares live in. A fresh tmpfs there hides every directory the image prepared underneath it: the install, the user state, the work directory, and the mount point the log share is attached to from fstab. A box would have come up with a socket and without any of the places its workload looks for its files, and the exact-path check could not notice, because what fstab mounts is a directory inside that tree rather than the tree itself. It moves to /run, which is where a runtime socket belongs, is a tmpfs already, and has nothing else mounted inside it. It was also owned by this process and closed to everyone else, which stopped the workload traversing it to reach the relay at all. The directory is now readable and searchable, and still writable by nothing but this process, which is what makes the socket in it unreplaceable; the socket itself is what the workload is allowed to connect to. The permission belongs on the socket rather than on the path. The address served to a reader was built once at startup and served forever, so a reader that polls for a better one could only ever get the first. An endpoint does not know all of its own addresses when it binds: the first is the one that works on the same network and fails from anywhere else. It is now rebuilt per read, which is what makes polling for it worth doing. And the address was taken from whoever held a path in a directory the workload can write. Workload code could unlink the socket a service was listening on, bind its own, and every read afterwards would hand the client an address of its choosing -- a session given to somebody else rather than a session that fails. The peer's credentials are now checked before a byte is read, from the kernel rather than from anything the peer says about itself, and an address served by the workload's own user is refused and said loudly. That check is only worth something while the workload has a user of its own, so the image grows one. Two users, and they must stay two: one runs the services that ship in the image, the other is who a workload runs as. Sharing one does not weaken the check, it makes every session fail it. A workload running as root is every user at once and cannot be told apart from anything; the check stands down there and says so at boot instead, because refusing root would refuse whatever legitimately serves the address as well. Also bumps tinyvec by a patch release. It does not build on this toolchain -- `vec` resolves to the module and not the macro -- which made every crate that depends on an endpoint, including this one, unbuildable. Pre-existing and nothing to do with this change; the lockfile said the same version before it.
build/ — the guest rootfs
Builds a bootable Artix/OpenRC image for the box's virtio-blk root: Mesa
(virtio-gpu native context) plus the four open guest components —
nescope, neshub,
neswire, nescapture — laid out
the way borealis
lays out its build/: one big multi-stage Dockerfile, --target picks the
flavor, etc/ holds the files that get overlaid onto the image verbatim.
build/
├── Dockerfile everything, in stages: mesa-build, nestri-build,
│ os-base, runtime, runtime_prod, runtime_debug
├── etc/ overlaid onto the image's /etc as-is
├── scripts/
│ └── mkimage.sh docker export → raw ext4, for nesbox's virtio-blk
├── Makefile
└── output/ `make image` writes here (gitignored)
make build # docker build --target runtime_prod → ghcr.io/nestrilabs/nestri/base:latest
make build-debug # docker build --target runtime_debug → ghcr.io/nestrilabs/nestri/base:debug
make image # + pack into output/rootfs.ext4
make image-debug # + pack into output/rootfs-debug.ext4
Design notes
Three things worth knowing about how this is put together:
-
No privileged host chroot. A bare
chrootinto a hand-extracted rootfs needs/proc,/sys,/devbind-mounted in first — they don't exist inside a chroot target until something puts them there.os-basehere isFROM artixlinux/artixlinux:base-openrcdirectly, withpacman -Sas plainRUNsteps — a Docker build step already runs inside a real container with its own/proc,/sys,/dev, so that whole bind-mount mechanism has nothing to do. -
No host-side ownership bug to guard against.
COPY --from=runs as root inside the build with no host user in the loop, so there's no invoking-user uid getting stamped onto/,/usr/bin, or anywhere else a build step touches — a failure mode some overlay approaches need an explicit sanity check for doesn't exist here to check for. -
One
cargo build --release --workspace, not one stage per binary.nescope,neshub,neswireandnescaptureshare one Cargo workspace and oneCargo.lock— a BuildKit cache mount ontarget/gives cargo's own incremental compiler per-crate isolation without needing a separate Docker stage (and a separate full rebuild ofnesprotocol) per binary.
What is deliberately not here: Proton, and Valve's steamclient.so.
nestri/CLAUDE.md is explicit — "Nothing closed may enter this repo. Not
source, not a dependency, not a directory that 'looked convenient'." Both
are closed. runtime_prod from this Dockerfile — tagged
ghcr.io/nestrilabs/nestri/base:latest — is a complete, bootable, Steam-less guest image,
and also the shared foundation other builds start from: nesbox's jail image
(see nesbox/build/) extracts Mesa from it so the guest and host sides of
the virtio-gpu native-context protocol never drift apart. Only Mesa —
virglrenderer is the host half of that protocol and nesbox builds its own,
patched, from nesbox/patches/; nothing in this image carries it.
Whatever layers Proton and the Steam client on top of it is a closed build outside this repo, by design — not something this repo names, links to, or depends on.
The nesinit gap
Nothing in this image starts a payload. The old nestri-guest-hub did that
— per its own commit message, the open neshub "loses --proton,
--steamclient-so, --root and the game uid/gid, and no longer ends by
handing the process to a controller... Deciding when the box is finished
belongs to nesinit." nesinit — the guest init/session-supervisor that
would actually launch nescope -- <payload> and power the box down — is
referenced in commit messages and nesbox/PROGRESS.md but does not exist as
open code in either repo.
So /etc/init.d/nescope here starts nescope in plain-compositor mode
(no command after --): it comes up, provides the Wayland/X11 environment,
and waits for something to connect. That makes the image genuinely bootable
and testable — neshub, neswire, nescope all come up under OpenRC and
you get a real Wayland socket to point a client at — but running an actual
game is still nesinit's job, and nesinit isn't part of this build. Whoever
picks that up next should read apps/neshub/README.md's "What it does not
do" section first.
Network defaults
/etc/init.d/guest-net reads nestri.ip=/nestri.gw= off the kernel
command line, falling back to 172.30.0.2/24 via 172.30.0.1 if neither is
set — nesbox's own default tap addressing. Keep these in step if that
changes on the nesbox side.