Skip to content

dist: use bubblewrap for overlayFS mounts, run sccache-dist without root#2728

Open
rrbutani wants to merge 1 commit into
mozilla:mainfrom
rrbutani:dist-without-root
Open

dist: use bubblewrap for overlayFS mounts, run sccache-dist without root#2728
rrbutani wants to merge 1 commit into
mozilla:mainfrom
rrbutani:dist-without-root

Conversation

@rrbutani

@rrbutani rrbutani commented Jun 6, 2026

Copy link
Copy Markdown

Note

I've opened this PR to get feedback on whether the direction here is acceptable. There are still a few items that need to be addressed (see pending below) before this is ready for merge.

The approach here is more or less the same as in #1628: use CLONE_NEWUSER (unprivileged user namespace) to be able to create a mount namespace + mount the overlayFS mounts without permissions

Unlike #1628, this PR leverages bubblewrap's overlay mount functionality (added in v0.11.0) to create the overlayFS mounts at the sccache-distbwrap compile command process boundary. This has a couple of upsides:

other notes:

  • previously deleting the build directory/the per-compile directories did not run into permission issues because sccache-dist was running as root

pending/open questions:

  • fallback support for running on Linux <5.11 and/or with bubblewrap versions older than v0.11.0?
  • fallback support for running on machines where unprivileged user namespaces are disabled?
  • manual checks for whiteout files/files with userxattr.overlay xattrs in the compile inputs tarball?
    • (see these docs for context)
    • previously this issue was sidestepped by unpacking directly into the overlay mountpoint (target dir); now that we're having bubblewrap handle creating the mountpoint this isn't an option
    • unclear to what degree this is an issue (does not seem like users could do anything nefarious with whiteouts or opaque dirs — worst case a toolchain file is masked?)
    • also: tar::Archive defaults to not restoring xattrs so I think the only consideration is whiteouts?

closes #326, closes #1660, closes #1688, supersedes #2706

@codecov-commenter

codecov-commenter commented Jun 6, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 0% with 30 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.53%. Comparing base (3bb4fc1) to head (223e16b).
⚠️ Report is 4 commits behind head on main.

Files with missing lines Patch % Lines
src/bin/sccache-dist/build.rs 0.00% 30 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2728      +/-   ##
==========================================
+ Coverage   73.38%   74.53%   +1.14%     
==========================================
  Files          70       70              
  Lines       39379    39642     +263     
==========================================
+ Hits        28900    29548     +648     
+ Misses      10479    10094     -385     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@rrbutani rrbutani marked this pull request as ready for review June 9, 2026 04:37
… root

the approach here is more or less the same as in mozilla#1628: use
`CLONE_NEWUSER` (unprivileged user namespace) to be able to create a
mount namespace + mount the overlayFS mounts without permissions

unlike mozilla#1628, this PR leverages [`bubblewrap`'s overlay mount functionality](containers/bubblewrap@f371022)
(added in `v0.11.0`) to create the overlayFS mounts at the
`sccache-dist` → `bwrap` compile command process boundary. This has a
couple of upsides:
  - sidesteps the [safety issues](https://github.com/mozilla/sccache/blob/9fb6a2542c0d2e82846252be19bb377e5ca8885b/src/bin/sccache-dist/build.rs#L447-L458)
    in mozilla#1628 caused by forking the `sccache-dist` process
  - avoids the [issue](mozilla#1688)
    with overlay fs mounts not being unmounted once the compile command
    finishes that ultimately led to mozilla#1628 being
    [reverted](mozilla#1689)
    + though, I think this issue was actually caused by mozilla#1628 changing
      the default sandboxing codepath (i.e. `current_ns`) to call
      `CLONE_NEWNS` [in the `sccache-dist`'s `rouille` request handler thread](https://github.com/mozilla/sccache/blob/9fb6a2542c0d2e82846252be19bb377e5ca8885b/src/bin/sccache-dist/build.rs#L422-L429) instead of [in the thread spawned for a compile](https://github.com/mozilla/sccache/blob/c72eed63d78c8550b93133e9fa461a0c6ef7a30d/src/bin/sccache-dist/build.rs#L272-L276)
      (and not anything to do with the unprivileged user namespace
      logic)

other notes:
  - previously deleting the build directory/the per-compile directories
    did not run into permission issues because `sccache-dist` was
    running as root

closes mozilla#326, closes mozilla#1660

closes mozilla#1688

supersedes mozilla#2706
@rrbutani rrbutani force-pushed the dist-without-root branch from 223e16b to 03b3fcf Compare June 9, 2026 04:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants