Cached tasks cannot spawn child processes inside a rootless bubblewrap sandbox (EPERM)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- linux, rust
- Domain
- operating-systems, security, tooling
Research direction
Reproduce the failure with the provided rootless bubblewrap command and compare cached versus cache-disabled tasks using vp run -r test. Start by tracing the fspy_preload_unix path and child-process setup; done means cached tasks can spawn in this sandbox, or tracking degrades without blocking the exec.
Written by the indexing model from the issue text.
Description
Summary
Inside a rootless bubblewrap sandbox, a cache-enabled task cannot spawn child processes. Every spawn/spawnSync/execFile fails with EPERM before the child runs. Setting cache: false on the same task, with nothing else changed, makes it work.
The path is absolute and executable in both cases, so this is not PATH resolution.
Reproduction
Sandbox is entered as:
bwrap --die-with-parent --new-session \
--unshare-user --unshare-pid --unshare-ipc --unshare-uts --unshare-cgroup --unshare-net \
--cap-drop ALL \
--clearenv --setenv PATH /runtime/bin \
--ro-bind <toolchain-image> /runtime \
--tmpfs /tmp --dev /dev --proc /proc \
--bind <checkout> /workspace \
-- /runtime/bin/sh -c 'cd /workspace && vp run -r test'
There is no /usr/bin, /bin or /usr/lib in the sandbox; everything is under /runtime.
Any cached task whose command spawns a child reproduces it:
execFileSync("/tmp/shell/sh", ["-n"], { input: script });
| task config | spawn |
|---|---|
{ command: 'vp test' } |
EPERM |
{ command: 'vp test', cache: false } |
works |
In one vp run -r test over a workspace, the packages I had flipped to cache: false spawned fine while the packages still cached failed in the same run, same sandbox, same commit. Flipping two packages took the spawn failures from 74 to 0.
Observed
Error: spawnSync /tmp/shell/sh EPERM
Error: spawn EPERM
Nothing is printed by the child. git subprocesses fail the same way one level down:
fatal: cannot exec 'git-receive-pack': Operation not permitted
Environment
- vite-plus 0.3.0
- Linux x86_64, glibc
- rootless bubblewrap, seccomp, unprivileged user namespaces
Notes
Not #569/#576 — 0.3.0 has both. LD_PRELOAD is unset going in, so not #340.
Guess: fspy_preload_unix has to inject into each child, and this sandbox is --cap-drop ALL with /usr/lib unmounted, so either the preload object is unreachable in the child's mount namespace or something it does on init is denied — and the exec is refused instead of tracking degrading.
Falling back to caching without file tracking would be better than failing the spawn. Today the only workaround is disabling the cache for the whole package.
Happy to run patches or a debug build against the sandbox.
- Dominant language
- Rust
- Stars
- 466
- Forks
- 42
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 21
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from voidzero-dev/vite-task
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
voidzero-dev/vite-task#738 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 78/100
voidzero-dev/vite-task#719 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
voidzero-dev/vite-task#717 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
voidzero-dev/vite-task#702 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 78/100
voidzero-dev/vite-task#699 ·
All issues in voidzero-dev/vite-task
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#616 ·
-
bug rules
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
app bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
IronCoreLabs/ironcore-alloy#346 ·
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 65/100