-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo check --frozen
requires the cargo home to be writable on nightly
#6928
Comments
Other than All of this (especially source unpacking, I can work around the package cache thingy) is bad for Crater: we want as much as possible in the containers to be read-only to prevent all the damage misbehaving or malicious crates can do during a run, and locking down |
I think the read-only issue with extracting is due to this change: https://github.com/rust-lang/cargo/pull/6880/files#diff-ce3ac564b3688633fe9c7ccb934e6253L470 It previously was careful to open the lock in read-only mode, but it no longer does that. |
If it's needed I can work around the |
Previously Cargo would attempt to work as much as possible with a previously filled out CARGO_HOME, even if it was mounted as read-only. In rust-lang#6880 this was regressed as a few global locks and files were always attempted to be opened in writable mode. This commit fixes these issues by correcting two locations: * First the global package cache lock has error handling to allow acquiring the lock in read-only mode inaddition to read/write mode. If the read/write mode failed due to an error that looks like a readonly filesystem then we assume everything in the package cache is readonly and we switch to just acquiring any lock, this time a shared readonly one. We in theory aren't actually doing any synchronization at that point since it's all readonly anyway. * Next when unpacking package we're careful to issue a `stat` call before opening a file in writable mode. This way our preexisting guard to return early if a package is unpacked will succeed before we open anything in writable mode. Closes rust-lang#6928
Re-enable compatibility with readonly CARGO_HOME Previously Cargo would attempt to work as much as possible with a previously filled out CARGO_HOME, even if it was mounted as read-only. In #6880 this was regressed as a few global locks and files were always attempted to be opened in writable mode. This commit fixes these issues by correcting two locations: * First the global package cache lock has error handling to allow acquiring the lock in read-only mode inaddition to read/write mode. If the read/write mode failed due to an error that looks like a readonly filesystem then we assume everything in the package cache is readonly and we switch to just acquiring any lock, this time a shared readonly one. We in theory aren't actually doing any synchronization at that point since it's all readonly anyway. * Next when unpacking package we're careful to issue a `stat` call before opening a file in writable mode. This way our preexisting guard to return early if a package is unpacked will succeed before we open anything in writable mode. Closes #6928
Problem
On Rust 1.34.1, as long as all the dependencies were pre-fetched with
cargo fetch
, runningcargo check --frozen
never touched the~/.cargo
directory, allowing it to be read-only. This behavior is used by Crater to prevent misbehaving crates from messing up the cargo installation.The latest nightly instead requires that directory to be writable:
Steps
bash repro.sh stable
for the correct behaviorbash repro.sh nightly
for the wrong behaviorPossible Solution(s)
After talking to @Eh2406 the issue seems to be caused by #6880.
The text was updated successfully, but these errors were encountered: