Repository navigation
tinybox-jail: Windows AppContainer backend cannot be enabled (unsafe policy, no waitable Child) #22
Description
crates/tinybox-jail/src/windows.rs is not compiled, so on Windows pick_backend() returns the unsupported backend and a host that wants to run anyway has to opt into NoopBackend (unconfined).
Why it stays off
History: 40f2e4f (2026-09-30) removed the platform modules because they did not satisfy the workspace unsafe_code = "forbid" policy or the Jail contract. The Linux (Landlock) and macOS (Seatbelt) backends are re-enabled by the linked PR. Windows cannot be, for two independent reasons:
unsafe. The backend is Win32 FFI (CreateAppContainerProfile,SetNamedSecurityInfoW,CreateProcessWwithSTARTUPINFOEXW, handle/SID cleanup). AGENTS.md says no crate relaxes the forbid, and unlike Landlock there is no unsafe-free way to apply an AppContainer to a child.- No waitable
Child.JailBackend::spawnreturnsstd::process::Child, which has no stable constructor from a rawHANDLE.spawn_in_containercreates the process, then closes the handle and returnsUnsupported, which strands a running, unconfined-from-the-caller's-view process.is_available()is hard-coded tofalsefor that reason. - It has never run on real Windows hardware (the file header says so).
Options
- Move the AppContainer launch behind a helper process or an existing tool that owns the
unsafe(astinybox-linuxdid for namespaces), and have it exec/forward stdio. - Or change
JailBackend::spawnto return a crate-owned child type (id,wait,try_wait,kill) and carve the FFI into a crate that is explicitly allowedunsafeby an ADR.
Either needs a design decision, so this is tracked rather than done in the enable-backends PR.
Activity
tinysweeper commentedon Oct 3, 2026
Windows AppContainer backend cannot be enabled due to unsafe code and no waitable Child; needs a design decision before re-implementation.
Labelled
priority: p3.M3gA-Mind commentedon Nov 11, 2026
This looks done on main via #140 (from fork #66):
windows.rsis compiled on Windows, the AppContainer backend spawns through a crate-owned child (spawn_owned_captured, Job Object limits), and a CI script fences theunsafe.is_available()stays false only for thestd::process::ChildAPI.Closing once someone confirms the Windows default backend uses the owned path. Reopen if it doesn't.
M3gA-Mind commentedon Nov 11, 2026
Correction: this is not done yet. The AppContainer backend exists and is owned-spawn capable (windows.rs: is_owned_available() is true, spawn_owned_captured runs each child in its own Job Object), but the module never selects it.
The likely fix is to give those call sites the owned backend (JailLocalHost already spawns through spawn_owned_captured), then prove it on the Windows runner. Keeping this open until that lands.
The fix is in #164.