lxutil: use permissive drvfs modes by default without metadata

[benhillis]

lxutil: use permissive drvfs modes by default without metadata

Problem

When a drvfs volume is served without the metadata mount option (the default), newly created files come back to the Linux guest owned by the volume's default uid/gid (frequently 0/root) with ACL-derived, fmask-masked modes such as 0o644. A non-root guest user is then denied write access to files it just created.

This is a regression from the legacy 9p drvfs server, which exposes the permissive 0o777 default for non-metadata mounts. It surfaces most visibly under containers using a uid=0 bind mount over virtiofs, where a non-root process cannot write files it owns. See microsoft/WSL#40719.

Root cause

FsContext enables supports_permission_mapping for any local (non-remote) NTFS volume. With permission mapping on, convert_mode derives the Linux mode from the Windows ACL EffectiveAccess (0o666 for a normal writable file) and then masks it with the mount fmask (default 022), yielding 0o644. Because no-metadata mounts cannot record real ownership, the file also falls back to the volume default uid/gid. The combination (root owner + 0o644) blocks the non-root creator.

Permission mapping only makes sense when metadata is enabled, because without metadata there is no way to record real ownership and the per-class permission bits are advisory — the host ACL remains the real access gate regardless of the guest mode bits.

Change

In LxVolume::new, disable supports_permission_mapping whenever metadata is off, so the default mount uses the permissive legacy drvfs model (0o777, still clearing write bits for read-only files). Metadata mounts are unchanged and keep deriving modes from the Windows ACL and stored ownership.

if !options.metadata {
    fs_context
        .compatibility_flags
        .set_supports_permission_mapping(false);
}

Validation

• cargo check -p lxutil — passes.
• cargo test -p lxutil — 44 passed, 0 failed. No existing test asserts a specific no-metadata mode, so none regress.
• Audited the only other supports_permission_mapping consumer (the stat fallback in fs.rs): reachable only on legacy filesystems lacking FILE_STAT_INFORMATION, where granted_access = 0 is consistent with the permissive fallback path.

Filed as a draft for review of the approach before adding a regression test.

[github-actions]

⚠️ Unsafe Code Detected

This PR modifies files containing unsafe Rust code. Extra scrutiny is required during review.

For more on why we check whole files, instead of just diffs, check out the Rustonomicon

[Copilot]

Pull request overview

This PR adjusts Windows lxutil filesystem capability detection so that Linux permission “mapping” from Windows ACLs is disabled when the volume is mounted without metadata. This aligns no-metadata mounts with the legacy permissive drvfs behavior, avoiding guest-side VFS denials caused by restrictive mode bits combined with fallback (often root) ownership.

Changes:

• Make FsContext mutable in LxVolume::new so compatibility flags can be adjusted after mount-option normalization.
• Disable supports_permission_mapping whenever options.metadata is false (including when metadata is forced off due to filesystem limitations).
• Add detailed inline rationale explaining why ACL-derived modes are counterproductive without metadata-backed ownership.