Summary
The end-to-end isolation test the_isolation_actually_holds_against_a_live_container (in daemon/src/isolation.rs) is currently #[ignore]d in CI. On GitHub's shared runners, Docker maps the container's root to a subuid that can read the world-readable workspace files but cannot write back into a directory owned by the runner user, so the "workspace is writable" assertion fails — an artefact of that host's Docker uid mapping, not of the isolation. It passes on a normal machine where you own the workspace and run Docker as yourself.
The task
Give this real test a home in CI: add an opt-in job to .github/workflows/ci.yml that runs cargo test -- --ignored on ubuntu, made robust to the runner's Docker uid mapping. Likely one of:
- run the container as the host user (
--user $(id -u):$(id -g)), or
- make the sandbox dir group/other-writable in the test when it detects it's under CI, or
- use a rootless-Docker-friendly setup.
Whatever the fix, the network-off / read-only / cap-drop assertions must still mean what they say — don't weaken the security checks to make it pass.
Acceptance
- A CI job runs the live isolation test and is green on GitHub's ubuntu runner.
- The security assertions (
--network none actually blocks, root is read-only, workspace is writable) are all still exercised.
- The deterministic flag tests (
the_network_is_off_by_default, etc.) stay as they are.
Why "help wanted"
It needs a bit of Docker-on-CI knowledge and some trial-and-error against the runner environment — a satisfying, self-contained piece for someone who enjoys CI plumbing.
Summary
The end-to-end isolation test
the_isolation_actually_holds_against_a_live_container(indaemon/src/isolation.rs) is currently#[ignore]d in CI. On GitHub's shared runners, Docker maps the container's root to a subuid that can read the world-readable workspace files but cannot write back into a directory owned by the runner user, so the "workspace is writable" assertion fails — an artefact of that host's Docker uid mapping, not of the isolation. It passes on a normal machine where you own the workspace and run Docker as yourself.The task
Give this real test a home in CI: add an opt-in job to
.github/workflows/ci.ymlthat runscargo test -- --ignoredon ubuntu, made robust to the runner's Docker uid mapping. Likely one of:--user $(id -u):$(id -g)), orWhatever the fix, the network-off / read-only / cap-drop assertions must still mean what they say — don't weaken the security checks to make it pass.
Acceptance
--network noneactually blocks, root is read-only, workspace is writable) are all still exercised.the_network_is_off_by_default, etc.) stay as they are.Why "help wanted"
It needs a bit of Docker-on-CI knowledge and some trial-and-error against the runner environment — a satisfying, self-contained piece for someone who enjoys CI plumbing.