Bubblewrap  FirewallEnforced / ProxyOnly  network setup races with short-lived sandboxed processes —  slirp4netns / nsenter  fail with  /proc/<pid>/ns/net: No such file or directory #1378

Relevant area(s)

Linux

Brief description of your issue

When a network policy routes through  ResolvedNetworkMode::FirewallEnforced  or  ProxyOnly  (any policy that isn't a ruleless full  deny ), the Bubblewrap backend's supervisor script races against the sandboxed command's own process lifetime. If the sandboxed command exits before the supervisor finishes starting  slirp4netns  and attaching  nsenter --net=/proc/$child_pid/ns/net , setup fails with:

Bubblewrap: slirp4netns startup and network rule installation exited during startup (exit status: 1): stderr: /proc//ns/net: No such file or directory
child failed(1)
slirp4netns exited before signalling readiness

Root cause (from reading  proxy_network.rs )

The  SUPERVISOR_SCRIPT  embedded in  src/backends/bubblewrap/common/src/proxy_network.rs :

1. Reads  child_pid  from a pipe written by the parent.
2. Starts  slirp4netns --configure --mtu=65520 --ready-fd 9 --exit-fd 4 "$child_pid" tap0 .
3. Waits for slirp readiness, then runs  nsenter --net="/proc/$child_pid/ns/net" -- iptables-restore ... .

This assumes  $child_pid 's network namespace stays resolvable via  /proc/$child_pid/ns/net  for the duration of this setup. On a fast host, trivial sandboxed commands (e.g.  echo ,  pwd ,  whoami ,  id ) can exit and be reaped before the supervisor reaches step 2/3, so  /proc//ns/net  no longer exists and the whole sandboxed execution fails — even though the command itself would have succeeded instantly.

Evidence

• Manually reproducing  bwrap --unshare-net  +  slirp4netns  by hand with an explicit  sleep 2  inside the sandboxed child succeeds every time.
• Reproducing with a near-instant command (no sleep) fails with the exact error above, reliably.
• Disabling network entirely ( defaultPolicy / egress.default = deny , ruleless) routes to  ResolvedNetworkMode::Isolated  ( --unshare-net  only, no  slirp4netns ) and never fails — consistent with the bug being specific to the  slirp4netns / nsenter  handoff timing, not Bubblewrap itself.
• This reproduces on every invocation on this host, not intermittently — suggesting the setup phase here is consistently slower than process exit+reap for trivial commands.

Environment

• OS: Gentoo Linux, kernel  6.18.52-gentoo  (custom build, compiled day of testing)
• CPU: Intel Core i9-13900KS (very fast single-core perf, likely exacerbates the race)
•  bubblewrap  0.12.0
•  slirp4netns  1.3.4 (libslirp 4.9.1)
•  iptables  switched to  nf_tables  backend via  update-alternatives 
• Reproduced via GitHub Copilot CLI's  /sandbox  local sandboxing feature (experimental), which uses this backend.

Suggested fix direction

The supervisor should hold a durable reference to the sandboxed namespace independent of the workload process's own lifetime — e.g. keep an extra bind-mounted reference to the netns ( mount --bind /proc/$child_pid/ns/net /some/persistent/path ) or an open file descriptor to it before publishing readiness/starting the workload, rather than relying on the workload PID still being alive and un-reaped at arbitrary later points in supervisor startup.

Steps to reproduce

1. On a Linux host meeting all documented prerequisites ( bwrap  ≥0.5.0,  slirp4netns ,  unshare / nsenter  ≥2.35,  iptables / ip6tables  on the  nf_tables  backend,  /dev/net/tun  accessible), enable a network policy that is not a ruleless full deny — e.g. full outbound allow with no host restrictions ( allowOutbound: true ,  allowLocalNetwork: true , empty  allowedHosts / blockedHosts ), or any  allowedHosts /proxy configuration that resolves to  FirewallEnforced / ProxyOnly .
2. Run any trivial, near-instantaneous sandboxed command, e.g.:
   echo hello
   ``` or pwd, `whoami`, `id`.
3. Observe the sandbox execution fail during startup.
4. As a control, run the same sandboxed command but with an artificial delay before exit, e.g.:
   sh -c 'sleep 2; echo hello'

5. As a second control, switch the network policy to a ruleless full deny (routes to  ResolvedNetworkMode::Isolated ,  --unshare-net  only, no  slirp4netns ) and re-run the trivial command from step 2. Observe it succeeds.

### Expected behavior

Any sandboxed command — regardless of how quickly it exits — should execute successfully under a  FirewallEnforced / ProxyOnly  network policy, exactly as it does today under  Isolated  mode. Command runtime should have no bearing on whether sandbox network setup succeeds.

### Actual behavior

Trivial/near-instant commands reliably fail at sandbox startup with:

Bubblewrap: slirp4netns startup and network rule installation exited during startup (exit status: 1): stderr: /proc/<pid>/ns/net: No such file or directory
child failed(1)
slirp4netns exited before signalling readiness

The same command succeeds if an artificial delay is added before it exits, and fails 100% of the time (not intermittently) for instant commands on this host — consistent with the sandboxed workload process exiting and being reaped before the supervisor script (in  src/backends/bubblewrap/common/src/proxy_network.rs ,  SUPERVISOR_SCRIPT ) finishes reading  $child_pid , starting  slirp4netns --configure ... "$child_pid" tap0 , and running  nsenter --net="/proc/$child_pid/ns/net" -- iptables-restore ...  against it. Once the workload process has exited,  /proc/$child_pid/ns/net  no longer resolves, and the whole sandboxed execution is aborted — even though the underlying command itself would otherwise have completed successfully.