Does rustup.rs support shared .multirust (or whatever) directory?

[vi]

I want more than one UNIX user to have write access to shared multirust installation.

Is such mode supported/planned in the new rustup.rs? It should probably be like Git's core.sharedRepository setting, causing Cargo and other tools to create group-writable files and directories.

(I haven't actually experimented with it yet).

[brson]

It does not support it now, and I haven't considered exactly this scenario before.

It is related to the use case of installing rustup globally, or toolchains globally. Is it mostly the toolchains you want to share? I'm not sure if there's a use case for sharing anything else.

[alexchandel]

I'd like to install rustup.rs globally & install toolchains globally as well. The Rust installers can't install multiple targets on a host, so rustup.rs is really the only reliable way of installing and maintaining multiple Rust targets/toolchains. And it's critical to install globally on multi-user machines, because I don't want to use n_users*n_toolchains*100MB of HD space.

[brson]

Thanks for the feedback @alexchandel!

I'm afraid I still haven't put much thought into how global installation might work. Offhand I might expect that global rustup installation and global toolchain installation are two independent things. Maybe the -g flag to rustup-init writes the bins to /usr/local/bin and the -g flag to toolchain commands writes to somewhere globally. Lot of details to work out.

[Diggsey]

There's also two types of global toolchain installation:

1. A shared set of toolchains between all, or a group of users, that any user in that group can modify.
2. A set of toolchains that only root can modify.

In both cases, you'd want those toolchains to be "inherited" so that a user can still have a user-specific set of toolchains, and can switch between global and local toolchains easily.

One thing we should be very careful about is permissioning: whatever we do, we should make sure never to put root-owned files in the user's home directory, and should never do what npm install -g does, where the requirement to use sudo becomes contagious.

[brson]

One thing we should be very careful about is permissioning: whatever we do, we should make sure never to put root-owned files in the user's home directory, and should never do what npm install -g does, where the requirement to use sudo becomes contagious.

Yep, this is an easy mistake to make. Run rustup as sudo then settings.toml is mysteriously owned by root.

[alexchandel]

@brson Provisionally, I'd just like globally accessible toolchains. If I move rustup's folders from ~/.cargo and ~/.rustup to /opt/cargo and /opt/rustup and add /opt/cargo/bin to the path, will it work normally? As in, will toolchains continue to be installed to /opt/rustup and crates downloaded/cached in the user's home directory?

[jswrenn]

Any updates on this?

[Boscop]

Has anyone found a way to install rustup for all users so that it works?
@alexchandel This one didn't work: #1085 (comment)

[Diggsey]

@brson What do you think of this strategy:

Non-windows:

• Relax anti-sudo check, so that it succeeds if $UID or $SUDO_UID corresponds to the correct home directory, but it will call seteuid and setegid to switch to the original user before continuing
• Run anti-sudo check as the first step on every invocation of rustup, except proxies
• Add -g option to toolchain modification commands to install toolchains globally, by calling seteuid to temporarily switch back to root
• Global rustup directory controlled by $RUSTUP_GLOBAL_DIR, defaulting to /opt/rustup
• This directory has the same structure as ~/.rustup, but without a settings.toml file
• Rustup is installed globally by placing rustup-init in /usr/local/bin
• Each user can switch from a system-wide rust install to rustup by running rustup-init
• When rustup first creates /opt/rustup, it will automatically create a global linked toolchain named system, which points to the system-wide rust installation, if it exists

Windows:

• Add -g option to toolchain modification commands to install toolchains globally.
• If process needs to modify a global toolchain, and is not eleveated, use ShellExecute with the runas verb to self-elevate via the UAC prompt
• Global rustup directory controlled by %RUSTUP_GLOBAL_DIR%, defaulting to C:\ProgramData\rustup
• Rustup is installed globally by installing rustup-init to C:\Program Files\rustup and creating a start-menu shortcut which runs rustup-init
• When rustup first creates C:\ProgramData\rustup, it will automatically create a global linked toolchain for each rust installation installed using the old installer, and named appropriately with a system- prefix

Both:

• Commands which resolve toolchain names, but do not modify them, will look for user-local toolchains first, and fall back to global toolchains if the first is not present
• Use the global:<toolchain> syntax to explicitly choose the global toolchain if there is a local toolchain with the same name

[vi]

@Diggsey , Is modifying un-tar-ring to respect umask deliberately omitted?

This seems to be the only missing piece for sharing Rust between two accounts (both having write access) without root by using sticky bit on directories.

[Diggsey]

@vi I was focusing on global toolchains in the style of npm, where root is required to install globally.

You seem to be suggesting a different feature - the ability to have two or more users share the same RUSTUP_HOME directory - what exactly needs to change wrt permissioning for that to work?

[vi]

@Diggsey, Unpacking crates (tar archives) should ignore file modes except of +x. In other words, behave like in Git.

Shared group, g+rwx, sticky group bit and umask 002 (instead of usual 022) on rust home directory should make all files created there fully accessibly to the group, not just one user. Except of when access modes are changed explicitly, which happens when cargo unpacks crates (because of file and directory permission bits are stored in tar archives and usually it is 0644/0755, corresponding to the default umask 0022).