Conversation
PR Review SummarySize
Affected crates
Blast radius — ContainedThis PR touches: source code Updated automatically on each push to this PR. |
There was a problem hiding this comment.
Code Review
This pull request introduces detection for unsupported filesystems (specifically 9P/v9fs, commonly used in WSL2 and QEMU virtfs) where Landlock enforcement is unreliable, warning users to move their working directory to a native Linux filesystem. The review feedback suggests optimizing the warning deduplication logic by using the filesystem's device ID (u64) instead of PathBuf to correctly warn once per mount and avoid performing filesystem I/O inside the diagnostic loop. Additionally, a typo in the TMPFS_MAGIC constant value in the unit tests was identified and should be corrected.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Landlock grants for paths on 9P mounts (WSL2 Windows host paths under /mnt/c, /mnt/d, QEMU virtfs) are accepted by the kernel but silently have no enforcement effect, or are incompletely enforced depending on the kernel version. This leaves the sandbox in an undefined state: paths the user granted may remain blocked (default-deny fires) or unrestricted (grant is a no-op), with no indication why. Emit a warning before adding a Landlock rule for any path on a 9P filesystem so users know their sandbox has a hole on that path and are directed to move their working directory to a native Linux filesystem. Detection uses statfs(2) and checks f_type against V9FS_MAGIC (0x01021997). The syscall is skipped entirely for paths not under /mnt to avoid any overhead on the common case. Warnings are deduplicated per path so a profile with many capabilities under the same mount emits one warning, not one per capability. Signed-off-by: Aleksy Siek <aleksy@alwaysfurther.ai>
Linked Issue
Closes #1203
cc @Lugribossk with this, we can have a clear reason (differing filesystem) rather than a weird limbo state where you do not exactly know why it was enforced/not enforced.
Summary
Landlock grants for paths on 9P mounts (WSL2 Windows host paths under /mnt/c, /mnt/d, QEMU virtfs) are accepted by the kernel but silently have no enforcement effect, or are incompletely enforced depending on the kernel version. This leaves the sandbox in an undefined state: paths the user granted may remain blocked (default-deny fires) or unrestricted (grant is a no-op), with no indication why.
Emit a warning before adding a Landlock rule for any path on a 9P filesystem so users know their sandbox has a hole on that path and are directed to move their working directory to a native Linux filesystem.
Detection uses statfs(2) and checks f_type against V9FS_MAGIC (0x01021997). The syscall is skipped entirely for paths not under /mnt to avoid any overhead on the common case. Warnings are deduplicated per path so a profile with many capabilities under the same mount emits one warning, not one per capability.
Test Plan
Checklist
CHANGELOG.mdif needed