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.54%. Comparing base (5d52f91) to head (03b3fcf).
⚠️ Report is 13 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   74.51%   74.54%   +0.02%     
==========================================
  Files          70       70              
  Lines       39652    39642      -10     
==========================================
+ Hits        29546    29550       +4     
+ Misses      10106    10092      -14     

☔ 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
@rrbutani

Copy link
Copy Markdown
Author

@sylvestre friendly ping; is there anything I can do to make this PR easier to review?

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