Bind mounts leak host uid/gid into guest, blocking non-root workflows

[ariofrio]

On a bind-mounted volume, files owned on the host by the user who ran msb surface inside the guest with the raw host uid (e.g. 501), not a guest-meaningful identity. Non-root guest processes can't read/write/delete those files, and the usual chown workaround inside the guest doesn't stick for files the host creates afterwards.

Related: #707, #667 (both touch the same vm.rs bind-mount config path); #456 (where --user was added); #390 (passthrough fs origin).

Description

• The passthrough FS overlays a 20-byte user.virtiofs.override xattr on every stat reply (patched_stat). The xattr supplies the guest-visible uid/gid/mode.
• Files that have no override xattr fall through patched_stat to the raw host stat — so the guest sees the host uid/gid directly.
• New host-created files never get an xattr, so they always show up in the guest with the msb-process uid.
• do_setattr writes uid/gid changes into the xattr only — it never calls real fchown (FS server lacks CAP_CHOWN). So in-guest chown is xattr-only too.
• That means the common workaround — chown -R $guest_uid /mount from inside the guest — sticks only for the files that already exist at chown time. Anything the host writes after that surfaces as the host uid again.
• --user (the guest user identity) is resolved against the guest's own /etc/passwd by agentd inside the guest; the host has no idea what numeric uid e.g. --user appuser will be until the guest tells it. So there's currently no plumbing for the FS server to know what guest identity to map onto.

Reproduction

# host (macOS, uid 501)
mkdir ~/bind-demo && echo hello > ~/bind-demo/host.txt
stat -f '%Sp uid=%u(%Su) gid=%g(%Sg) %N' ~/bind-demo/host.txt

msb run ubuntu --volume ~/bind-demo:/work --user 1000:1000 -- sh -c \
  'id; ls -la /work; (echo append >> /work/host.txt) 2>&1; echo exit=$?'

Actual Behavior

-rw-r--r-- uid=501(ariofrio) gid=20(staff) /Users/ariofrio/bind-demo/host.txt
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),...
drwxr-xr-x+ 3 501 dialout 96 /work       # raw host uid leaks; gid 20 maps to ubuntu's "dialout"
-rw-r--r--+ 1 501 dialout  6 /work/host.txt
sh: 1: cannot create /work/host.txt: Permission denied
exit=2

Same thing happens for the chown workaround: in-guest chown -R 1000:1000 /work sticks for existing files (xattr is set), but any file the host creates after the chown shows up in the next guest session as uid 501 again — because the new file has no xattr and patched_stat falls through to the raw host stat.

Expected Behavior

uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),...
drwxr-xr-x+ 3 ubuntu ubuntu  96 /work    # appears as the sandbox user
-rw-r--r--+ 1 ubuntu ubuntu   6 /work/host.txt
exit=0                                    # write succeeds

Non-root guest workflows over a bind mount should work without requiring the user to manually align identities. Host-side file edits should remain accessible from the guest as the sandbox's --user identity.

Workaround

# either run the guest as root (defeats the purpose of --user)
msb run ubuntu --volume ~/bind-demo:/work -- ...

# or align the host uid to the guest uid before launching
# (only practical if you control the host setup)

In-guest chown -R $guest_uid /work only fixes already-existing files. New host writes still leak through as host uid.

Relevant Code

• crates/filesystem/lib/backends/shared/stat_override.rs:63-110 — patched_stat overlays the xattr; for files without an xattr it returns the raw host stat (this is where the leak surfaces).
• crates/filesystem/lib/backends/passthroughfs/metadata.rs:94-128 — do_setattr's uid/gid/mode branch writes only to the xattr; comments at lines 10-12 confirm fchown/fchmod are deliberately not used (no CAP_CHOWN).
• crates/filesystem/lib/backends/passthroughfs/inode.rs:962-1003 — stat_inode is the chokepoint; every guest-visible stat funnels through it into patched_stat. A change here covers do_getattr, do_setattr's return, do_access, and the lookup path.
• crates/filesystem/lib/backends/passthroughfs/metadata.rs:174-216 — do_access reads from stat_inode, so any uid/gid surfaced by patched_stat already participates in the in-guest permission check.
• crates/agentd/lib/session.rs:554-605 — resolve_user_spec resolves --user via getpwnam_r against the guest's /etc/passwd; runs inside the guest at exec time.
• crates/agentd/lib/init.rs:20-44 — init::init runs as PID 1 inside the guest; apply_dir_mounts at line 27 is where bind mounts are actually attached to the guest namespace (so the bind mount isn't visible to any guest process until agentd has run).
• crates/agentd/bin/main.rs:29-83 — agentd reads MSB_USER from env on startup, runs init::init synchronously in Phase 1, then opens the virtio-serial control channel in Phase 2.
• crates/agentd/lib/agent.rs:60-107 — virtio-serial port is opened in Phase 2; the core.ready payload is sent over it.
• crates/runtime/lib/vm.rs:658-675 — bind-mount PassthroughFs backends are constructed here. Only these (not rootfs/runtime mounts) would need a mapping handle.

Acceptance Criteria

• Host files owned by the msb-process uid appear inside the guest as the sandbox's resolved --user identity, without requiring any in-guest chown.
• Host files owned by other uids appear inside the guest as the overflow uid (65534).
• Files with an existing override xattr still surface with the xattr's uid/gid (mapping is fallback-only, takes lower precedence).
• A non-root guest (--user 1000:1000) can read/write/delete host-created files in a bind mount when host mode permits.
• No regression for rootfs / runtime / non-bind-mount PassthroughFs instances (which legitimately need raw passthrough of identity from inside an OCI image).
• Test coverage: bind-mount write from non-root guest succeeds against a host-owned target.

[ariofrio]

Proposed direction (for discussion)

Add a uid/gid mapping that's consulted whenever patched_stat falls back to raw host metadata (i.e. the file has no override xattr). The mapping is configured per PassthroughFs instance — it's set only on the bind-mount backends, not on the rootfs or runtime mounts — and it's populated at boot with the numeric uid/gid that --user resolves to inside the guest.

When the mapping applies, the rule is:

• If the file's host uid matches the uid of the user who ran msb, present it inside the guest as (target_uid, target_gid) — where target_uid and target_gid are whatever --user resolved to.
• Otherwise, present it as 65534 / 65534 (the kernel's overflow uid and gid; the name varies by distro — nobody, and either nogroup or nobody).

The xattr override layer is unchanged. When a file has an override xattr, that wins; the mapping is purely a fallback.

Implementation

The change touches three places:

• PassthroughFs gains a configurable mapping field — something like Arc<RwLock<Option<UidGidMap>>> with a setter — and patched_stat (in crates/filesystem/lib/backends/shared/stat_override.rs:63-110) consults it in the no-xattr branch. Every guest-visible stat funnels through stat_inode and patched_stat, so this one change covers do_getattr, the post-write stat returned by do_setattr, do_access, and the lookup path. No other call sites need to change.

• In crates/runtime/lib/vm.rs:658-675 — the for mount_spec in &vm.mounts loop that constructs bind-mount backends — the new field is set on each bind-mount PassthroughFs. The rootfs and runtime mounts in the same file are constructed separately and don't get the mapping; they legitimately want raw passthrough of identity from inside the OCI image.

• Agentd resolves MSB_USER early in init::init, before apply_dir_mounts (crates/agentd/lib/init.rs:27), so the rootfs's /etc/passwd is in place regardless of whether the rootfs came in via passthrough or via disk-image + pivot_to_newroot. The existing resolve_user_spec (crates/agentd/lib/session.rs:554) does the work via getpwnam_r. The resolved (uid, gid) is shipped to the host as part of the existing Ready payload: add a new field to the struct definition at crates/protocol/lib/core.rs:15-28 (something like user_resolved: Option<(u32, u32)>) and populate it at the instantiation site in crates/agentd/lib/agent.rs:95-107. The host's core.ready handler picks it up and sets the mapping on each bind-mount backend for that sandbox.

Design decisions

Timing of the resolve-and-report

The virtio-serial control channel doesn't open until Phase 2, after init::init returns. So the resolution can't reach the host before apply_dir_mounts actually mounts the bind mounts. Three reasonable options:

1. Resolve during init, ship in core.ready (this is what I'm thinking). This is the smallest delta. There is a theoretical window between when bind mounts come up and when the host receives core.ready and updates its mapping. In practice the window should be empty: nothing in agentd's boot path touches the bind mount after mounting it, and the agent loop is just sitting waiting for the first msb exec. By the time anything in the guest stat's a bind-mounted file, the host has the mapping.

2. Open virtio-serial early in init. This sends the resolution before apply_dir_mounts, eliminating the window entirely. The complication is the single-open constraint at crates/agentd/lib/agent.rs:64-66 — only one process can hold the virtio-console port open at a time. Doing this means refactoring fd ownership between the early-init code and the async agent loop.

3. Reorder apply_dir_mounts to after core.ready. No race at all — the mounts only happen once the host has confirmed receipt of the resolution. This changes the semantics of "init complete," which the --init=systemd handoff at crates/agentd/bin/main.rs:59 depends on. Larger blast radius.

Option (1) seems the cheapest fix with the smallest risk. (2) and (3) are available as future tightenings if anyone ever actually hits the window.

Gid policy

The gid surfaced by the mapping doesn't matter for most access checks. do_access consults the gid only when the calling process isn't the file's owner and the file's mode gives group strictly more access than other — e.g. modes like 0o640 or 0o660. For default modes (0o644, 0o755) the gid is irrelevant.

That gives us flexibility on what to surface:

• Mapped case (file's host uid is the msb-process uid): use target_gid. The guest process matches as the file's owner, so the access check uses the owner bits and the group bits aren't consulted. The gid is essentially just there for display in ls -la and similar.

• Unmapped case: use 65534. The reason for not passing the raw host gid through is that on a guest where the calling process's primary gid happens to equal the host's gid (e.g. both are 1000), a 0o640 file would unexpectedly grant the guest read access via the group-bits path. Using 65534 closes that.

A third option — passing the raw host gid through directly — is wrong for a separate reason: on macOS, file gids are inherited from the parent directory (BSD semantics, unconditional). So the host gid of a typical file often reflects the parent directory's group (wheel for files under /tmp, staff for files under ~) rather than anything semantically meaningful inside the guest.

Tradeoffs and limitations

• In-guest chown -R still doesn't reach the host file's real owner. This is a known consequence of the FS server lacking CAP_CHOWN, and it's not fixable without privilege. It's mostly subsumed in practice by the mapping itself: once the mapping is in place, users don't need to chown host-created files at all, because they already appear with the right guest identity.

• msb exec --user other doesn't update the mapping. The per-exec override at crates/microsandbox/lib/sandbox/exec.rs:184 lets a single sandbox run different exec sessions under different identities. The mapping is global to the FS server, though, and stays pinned to the sandbox's initial --user. That's stable and predictable. An in-guest chown can still override per-file (writes the xattr, which takes precedence over the mapping).

Open questions

• Is option (1) for the resolve-and-report timing acceptable, or do you want (2) or (3) up front?
• Should the mapping be unconditional for bind mounts, or gated behind a config flag in case someone wants today's "raw passthrough" behavior preserved?
• For multi-user bind mounts (rare): is "msb-process owner → mapped, everything else → overflow" the right policy, or do you want more nuanced control?