Skip to content

deps: Switch libmount to sys-mount#2706

Open
luhenry wants to merge 1 commit into
mozilla:mainfrom
luhenry:deps-libmount
Open

deps: Switch libmount to sys-mount#2706
luhenry wants to merge 1 commit into
mozilla:mainfrom
luhenry:deps-libmount

Conversation

@luhenry

@luhenry luhenry commented May 12, 2026

Copy link
Copy Markdown

libmount hasn't been updated in over 6 years [1], has equally old dependencies and even depends on packages which known CVEs [2]. sys-mount on the other hand is updated still regularly and the dependencies aren't ancient.

[1] https://crates.io/crates/libmount
[2] https://nvd.nist.gov/vuln/detail/CVE-2021-45707 for nix 0.14

libmount hasn't been updated in over 6 years [1], has equally old dependencies
and even depends on packages which known CVEs [2]. sys-mount on the other hand
is updated still regularly and the dependencies aren't ancient.

[1] https://crates.io/crates/libmount
[2] https://nvd.nist.gov/vuln/detail/CVE-2021-45707 for nix 0.14
rrbutani added a commit to rrbutani/sccache that referenced this pull request Jun 9, 2026
… 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant