Description of the task
The filesystem-policy checks that run just before a sandbox launches perform
synchronous host filesystem I/O per policy path, on the runner's launch
thread, with no timeout or cancellation:
wxc_common::filesystem_object::normalize_object_conflicts — object-identity
probe per path (std::fs::metadata on Unix; CreateFileW +
GetFileInformationByHandleEx on Windows).wxc_common::filesystem_access::check_delegation — access probe per path
(access(2) on Unix; CreateFileW on Windows).
These run on the critical launch path of the Bubblewrap, LXC, and WSLC backends.
A path that points at a dead autofs/NFS mount, an offline UNC share, or a
blocking special file can cause the probe to block, halting sandbox startup
indefinitely — there is no upper bound on how long a launch can hang.
Bound this so a pathological path can't stall startup. Options to evaluate:
- A per-path timeout that fails open with a warning (skip the check for that
path rather than hang), consistent with how the checks already treat
undeterminable paths.
- Running the probes on an abandonable worker (or otherwise off the critical
launch thread) so a blocked call can be dropped.
The fix should cover both modules, since they share the same launch-thread
I/O pattern.
Additional context
- Raised in review of the object-based filesystem-policy validation (D6) work and
applies equally to the delegation check (D3).
- Roadmap:
docs/linux-wsl-roadmap-june-2026.md.
- Related code:
src/core/wxc_common/src/filesystem_object.rssrc/core/wxc_common/src/filesystem_access.rs- Call sites:
src/backends/bubblewrap/common/src/bwrap_runner.rs,
src/backends/lxc/common/src/lxc_runner.rs,
src/backends/wslc/common/src/wsl_container_runner.rs
- Acceptance: no single unreachable/blocking policy path can hang sandbox startup
beyond a bounded time; timeout behavior is documented (fail-open + logged).
Description of the task
The filesystem-policy checks that run just before a sandbox launches perform
synchronous host filesystem I/O per policy path, on the runner's launch
thread, with no timeout or cancellation:
wxc_common::filesystem_object::normalize_object_conflicts— object-identityprobe per path (
std::fs::metadataon Unix;CreateFileW+GetFileInformationByHandleExon Windows).wxc_common::filesystem_access::check_delegation— access probe per path(
access(2)on Unix;CreateFileWon Windows).These run on the critical launch path of the Bubblewrap, LXC, and WSLC backends.
A path that points at a dead autofs/NFS mount, an offline UNC share, or a
blocking special file can cause the probe to block, halting sandbox startup
indefinitely — there is no upper bound on how long a launch can hang.
Bound this so a pathological path can't stall startup. Options to evaluate:
path rather than hang), consistent with how the checks already treat
undeterminable paths.
launch thread) so a blocked call can be dropped.
The fix should cover both modules, since they share the same launch-thread
I/O pattern.
Additional context
applies equally to the delegation check (D3).
docs/linux-wsl-roadmap-june-2026.md.src/core/wxc_common/src/filesystem_object.rssrc/core/wxc_common/src/filesystem_access.rssrc/backends/bubblewrap/common/src/bwrap_runner.rs,src/backends/lxc/common/src/lxc_runner.rs,src/backends/wslc/common/src/wsl_container_runner.rsbeyond a bounded time; timeout behavior is documented (fail-open + logged).