search

rust-lang / cargo

The Rust package manager
https://doc.rust-lang.org/cargo
Apache License 2.0
12.8k stars 2.43k forks source link

cargo install fails with tmpdir noexec #4350

Open fmarier opened 7 years ago

fmarier commented 7 years ago

My /tmp directory is mounted as noexec from within /etc/fstab:

tmpfs    /tmp    tmpfs    size=1024M,noexec,nosuid,nodev    0    0

and when I try to install sccache, I get the following error:

$ cargo install sccache
    Updating registry `https://github.com/rust-lang/crates.io-index`
  Installing sccache v0.2.0
 Downloading hyper v0.11.2
...
   Compiling app_dirs v1.1.1
error: failed to run custom build command for `rayon-core v1.2.1`
could not execute process `/tmp/user/1000/cargo-install.aYBrcIx53fYu/release/build/rayon-core-68aa2a81ce933a70/build-script-build` (never executed)
Build failed, waiting for other jobs to finish...
error: failed to compile `sccache v0.2.0`, intermediate artifacts can be found at `/tmp/user/1000/cargo-install.aYBrcIx53fYu`

Caused by:
  build failed

It would be nice if cargo could either use a different directory to put executables in, or at the very least warn about this limitation and give a clearer error message.

albel727 commented 7 years ago

Just mentioning the obvious, in case someone stumbles on this, but cargo internally uses tempdir crate, which in turn uses std::env::temp_dir(). Which means that on linux it consults $TMPDIR environment variable (and nothing else, like $XDG_RUNTIME_DIR, which happens to be not noexec for me, sigh) before falling back to /tmp.

And indeed, TMPDIR=$XDG_RUNTIME_DIR cargo install CRATE fixes cargo install for me.

stale[bot] commented 6 years ago

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

fmarier commented 6 years ago

This is still an issue. The reproduction steps in https://github.com/rust-lang/cargo/issues/4350#issue-247238683 are still accurate and the work-around in https://github.com/rust-lang/cargo/issues/4350#issuecomment-340215811 still works.

gilescope commented 5 years ago

I ran into this on a portable VSCode install on windows. I've raised https://github.com/microsoft/vscode/issues/83998 with them.

Pragmatically any temp dir that's accesssable and writable is fair game. Could we check if it's writable before we use it?

Feel free to label this with 'enterprise-adoption-papercut' or some such as it's enterprises that lock down temp dirs.

ShadowJonathan commented 3 years ago

This is still a problem, i just encountered this.

amrroq commented 2 years ago

Issue still exists, but the workaround provided by albel727 works like a charm!! So grateful! Been trying to find a solution to this for quite some time--never thought to check fstab to see that my /tmp directory is mounted as noexec.

sanmai-NL commented 1 year ago

See https://github.com/kubernetes/kubernetes/issues/48912

There's a common control that requires noexec for tmpfs mounts. This means Cargo is to be changed.

epage commented 1 year ago

So far the proposed solutions are

Some initial questions that need to be worked out for this to move forward

johnallsup commented 1 year ago

The cargo command must be called cargo as it uses its executable name to determine what it is. My first attempt at a cargo-specific TMPDIR was to rename cargo to cargo-real and then have a bash script set TMPDIR and then pass its arguments to cargo. This didn't work. So what I ended up with was (this is on Linux):

  1. mkdir /path/to/cargo/tmp (or somewhere, wherever you want tmp files to go)
  2. mkdir ~/.cargo/bin/real
  3. mv ~/.cargo/bin/cargo ~/.cargo/bin/real
  4. Create an executable bash script ~/.cargo/bin/cargo with the following content: 
    #!/bin/bash
export TMPDIR=/path/to/cargo/tmp
~/.cargo/bin/real/cargo "$@"

    Hopefully this illustrates how to wrap binaries with simple scripts to set things like environment variables. (For example with nvim I use this trick so that e.g. chad loads nvim with its config from ~/.config/NvChad rather than ~/.config/nvim as another example of this trick.)

Michaelschnabel-DM commented 1 year ago

Hi,

I am having a similar issue where the IT policy of my company restricts .exe files inside the TMP folder to be executed. What would be a proper workaround for that?

Thanks

ChrisDenton commented 1 year ago

I am having a similar issue where the IT policy of my company restricts .exe files inside the TMP folder to be executed. What would be a proper workaround for that?

A workaround might be to try setting the TMP environment variable in the console to somewhere you can run exe files from.

weihanglo commented 1 year ago

Per-user build cache may help here https://github.com/rust-lang/cargo/issues/5931, if we move install temporary directory into it.

epage commented 1 year ago

Per-user caches won't completely solve it because we'll still be compiling to the target directly for anything not (yet) in the cache. If we had rust-lang/rfcs#3371 and made it the default, even for cargo install, then that might do it.