-
Normalize the agent rootfs's owner-only Alpine paths at build time so pack create works for a non-root user on a packaged install (#872)
发布于
2026-08-12 04:30:31 +00:00 | 221 次提交 在此版本后已推送到 mainThe stock Alpine minirootfs ships four paths only their owner can read:
/root (0700), /etc/shadow (0640), /etc/crontabs/root (0600) and
lib/apk/db/lock (0600). packaging/arch/PKGBUILD and packaging/nfpm.yaml both
copy the tree mode-preservingly, so on a system-wide install they land
root-owned under /usr/lib/smolvm/agent-rootfs, unreadable to the user running
smolvm.collect_agent_rootfs tars the whole rootfs and cannot skip anything, so
pack createhard-fails there with "Permission denied". The same path is
reached by plainmachine runwhenever an init layer is baked via
pack create --from-vm— a Smolfile with [dev] init steps, or any
--oci-cache run — so those break too. Booting was never affected: the guest
never opens these files, and since the vsock readiness doorbell the host no
longer writes into this directory either.Widen the four by name after the build, plus the tree root itself, which is
created under the builder's umask and would otherwise be untraversable under a
restrictive one. Nothing is disclosed: this tree is a public release artifact,
byte-identical for every user, and shadow carries no hashes (root:*, every
other account !), /etc/crontabs/root is the stock run-parts schedule, /root is
empty and the apk lock is zero bytes. Ownership and write bits are unchanged.Then verify the whole tree and fail the build on anything still owner-only,
rather than a blanketchmod -R a+rX. This script also runs against
user-supplied trees and SMOLVM_AGENT_ROOTFS can boot one, and the rootfs is
shared into every VM — so a recursive widen would quietly expose a custom
tree's 0600 registry token to every workload. A later Alpine bump that adds a
fifth owner-only path now stops the build instead of shipping a rootfs that
cannot be packed.The rootfs build only runs in the release workflow, so the new suite covers the
function directly against fixtures — no smolvm binary, no VM — and asserts both
halves: the stock layout is widened, and an unrecognized owner-only path fails
while being left at its original mode.Verified across a real uid boundary in an Alpine guest: with the four paths
root-owned at stock modes,taras uid 1000 fails on all four
("can't open 'etc/shadow': Permission denied", and so on for crontabs/root,
lib/apk/db/lock and root/); after normalization the same tar as the same user
exits 0 with every entry archived.Fixes #865.
Assisted-by: Claude Code: opus-5
下载附件