发布

  • 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)

    frostbyte_neo 发布于 2026-08-12 04:30:31 +00:00 | 221 次提交 在此版本后已推送到 main

    The 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 create hard-fails there with "Permission denied". The same path is
    reached by plain machine run whenever 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 blanket chmod -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, tar as 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

    下载附件