How to install Rust system-wide?

I think that running toolchain from the user space (~) and any binary from ~/.cargo could be unsafe as one bin can put the malware to another executive one that have write permissions from the current user. In Unix, it's better to store this data in protected shared location such as /usr/local or /var/lib

Can I setup this script to install Rust into custom location?

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

For cargo install .. I can use just cargo build --release then sudo install from to, but how to move the toolchains out from the current user namespace?

It can be done, with some limitations, and isn't something I'd recommend - with the exception of in a containerised, single-user environment.

For an example of what it takes - see my default rust dev-container setup devcontainers-pyo3/Dockerfile lines55-95 · MusicalNinjas/devcontainers-pyo3

This still has a few restrictions (or bugs in my setup). E.g. cargo binstall only runs via sudo ...

I wonder that nobody cares, so there is really no build-in option yet?

This is brought up from time to time on these forums. IIRC someone remarked that their system's package manager supported Rust and it did system-wide installations of it. As an alternative maybe you could check if your system has a package manager that does system-wide Rust installations? Or peek under the hood of package managers and see how they do their Rust installations (though I suspect that it may be far less useful than one might think, but it may be worth looking into nonetheless).

(As a side note, not requiring elevated privileges for installation/updates is a security feature as well).

As to why nobody cares: I can't answer that for anyone else, but for me personally I realized that the user-installation Just Works(tm), and in particular since I started using nightly (and update it frequently), I realized how nice it is to not have to run rustup through sudo. With that said, I would welcome the option to perform a system-wide installation.

I do not entirely follow the threat you describe, please correct me.

If something or somebody has write access to your home directory, it does not really matter if the toolchain binaries are writable or not, as something/somebody malicious can divert the commands with an addition to $PATH or shell alias.

A solution could be to use the nix package manager to install cargo, rustc, rust-analyzer, rustfmt, clippy, etc. nix stores the toolchain in a read-only /nix/store.

This will still not entirely protect you against rogue binaries in your home directory, but neither will any system wide installation of the toolchain.

More a case of it's really not a system concern:

  • On a true multi-user system (like uni servers were in the late 90's/early 00's - rare these days, I'd guess) then one user will want a specific pinned toolchain for one project, another uses current nightly, another has current beta, someone else has a pinned nightly, ... etc. So
    • the value of saving storage from multiple installs is only there when the number of users is absolutely massive (I'm being very generous here)
    • the whole thing needs to be world-writable (!), everyone get's sudo (!!) or the admins get no sleep ever ;-(
    • or you offer a limited selection which is detrimental.
  • On a system with a handful of users then you're back to the "I can haz sudo?" problem
  • On a single user system ... no difference really. I'm not sure I follow your initial security concern: at the end of the day you, the user, need to run the malicious command in the first place - maybe you're a little better off if you don't do that with sudo?

python (e.g.) is different: there needs to be a system-level interpreter for scripts AND still it is "very highly recommended" to have local level installs for each project - that needs extra tooling to work (uv, poetry, ...)

What's the treat model?

What this is protecting you from?

Please don't tell me “that's how things were always done”, that's not the answer — yes, “it was always done that way” is a good start, that means that some time in the past there were some reasons to do things that way… but to decide whether it's still a good reason to continue you need to name these reasons, not just use an “it was always done that way” excuse.

I'm not sure it's a supported use case, but I've been able to mount my main user's .rustup folder as read-only in another users home folder, and it mostly worked (one linker was hard coding a path to the main user's home, so I had to patch that, I'm on mobile but can check details later).

Maybe if you setup a user to run the rustup toolchain updates/install, you can mount that user's rustup dir in other users home? (I was originally going to say "install rustup toolchains in root's home" but it seems unnecessary for rustup to run in a user with those permissions, all you need is the owner to be different from the users)