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

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).

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.

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.

@alexchandel

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.

There's also two types of global toolchain installation:

A shared set of toolchains between all, or a group of users, that any user in that group can modify.
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.

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.

@brson

@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?

Any updates on this?

@alexchandel

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

@brson

@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

@Diggsey

@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.

@vi

@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?

@Diggsey

@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).

@vi

@vi You might want to take a look at what @RalfJung is currently doing - #1141

@Diggsey

@Diggsey, It looks like a rustup.rs's pull request, but the problem is in Cargo.

@vi

@vi I'm not sure I follow: we were talking about a shared RUSTUP_HOME directory, but cargo doesn't put any files there. If there are no rustup changes to make, then I'm not sure what you meant by

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

This is the rustup issue tracker 😛

I though for a moment that it is about multi-user strategy for entire Rust, not just rustup.rs.

@brson

Any progress on this, @brson? I remember discussing this idea with you some time ago, when your multirust library was the thing.

Is there any progress on this issue? For my work we have several machines running Raspbian on ARM where the latest packaged version is 1.24, so it's very difficult to get work done without an update-to-date version of rust.

There has been no work on this, no. If you have ideas, I'm prepared to entertain approaches to make this sane and safe. (bear in mind rustup already has a whole host of "we don't lock stuff" problems)

I share .rustup between two user accounts, but run rustup only from one of them (it has umask 0002). Also the directly has sticky bit set. Seems to work.

As mentioned in #313 (comment), It looks like there are actually two separate feature requests here:

Have globally writable rustup installations, where any user can read/write to the directory (assuming sufficient permissions)
Have a globally readable installation.

#1085 is only for the second use case (which is my use case) but was closed as a dupe of this issue. Is is possible to try solving 2. before trying to solve 1? That seems to me like it would be a lot easier and fix the vast majority of use cases. #313 (comment) has lots of good suggestions which I don't think ever got a response.

A read-only rustup installation is not something rustup expects to deal with. You could be careful to not run anything which could cause writes to the installation (e.g. nothing which might force a toolchain to exist, so no use of rust-toolchain or use of, setting, removing, etc. overrides, no use of rustup default) but so many things expect to be able to run rustup commands to adjust the install that it'd be tough to enforce. At that point, an appropriate g+srx ought to be enough assuming by 'globally readable' you mean 'readable to a particular group' but ultimately this is not what rustup is for and we'd need to consider adjustments to the model to properly support this.

@jyn514

@jyn514 Try the method described in #2383.

@jyn514

@jyn514 It's not clear to me why a shared read-only install is 'your use case' - what is it about having several pi's that requires a shared installation: running rustup installed binaries on pi's doesn't seem to imply sharing those binaries between the pi's in any fashion. What is it about the regular installation path that doesn't work for your pi machines? Are they low on disk space? Is your NFS server short on disk space? Does rustup fail to unpack? (that should be fixed in the latest release now we auto-probe memory).

See #988 and #2417 for direct issues with sharing writable installs; if cargo's cache isn't shared then the cargo locking is probably avoidable from a scalability perspective, but you'll still be unable to use regular rustup workflows: vs-code integration / rls integrations / rustup update and frields, rustup default, rustup overrides, toolchain files, custom toolchains.

Note that we don't even guarantee arch-aware filepaths in ~/.rustup - sharing a rustup_home across architectures is not currently safe - settings.toml has a default-host that is arch specific, and sharing an install across heterogeneous machines over NFS would be broken by design.

@rbtcollins

@rbtcollins Sorry if I was unclear - I don't expect to share rustup across multiple machines, that's a much harder problem. I want to share rustup across multiple users.

What is it about the regular installation path that doesn't work for your pi machines?

The regular installation path is specific to each user. To expand a little more on this, we have a test suite that runs on several different machines at once, with the permissions of the user who started the test (we have automation internally to make sure each machine has each user). Currently, for it to work, each user has to have their own installation of rustup on each machine. This is not really tenable, it comes out to dozens (if not hundreds) of installations; we just haven't been running Rust tests on the Pis for now. I'm asking to be able to install rustup once on each machine and have it be accessible to each user.

See #988 and #2417 for direct issues with sharing writable installs; if cargo's cache isn't shared then the cargo locking is probably avoidable from a scalability perspective, but you'll still be unable to use regular rustup workflows: vs-code integration / rls integrations / rustup update and frields, rustup default, rustup overrides, toolchain files, custom toolchains.

Right, I'm only asking for read-only installs. See #313 (comment).

@jyn514

@jyn514 Can the method described in #2383 help you?

I wonder if Nix package manager could be of any help for a multi-user setup. Just a thought.

I wonder in Nix package manager could be of any help for a multi-user setup. Just a thought.

It's a nice idea, but sadly this requires system level support (ie. a user and a daemon) which, at least in the past, was out of scope for rustup.

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

brson commented on Apr 16, 2016

alexchandel commented on Jul 20, 2016

brson commented on Jul 26, 2016

Diggsey commented on Jul 26, 2016

brson commented on Jul 29, 2016

alexchandel commented on Jan 3, 2017

jswrenn commented on Mar 21, 2017

Boscop commented on May 5, 2017

Diggsey commented on Jun 3, 2017

vi commented on Jun 4, 2017

Diggsey commented on Jun 5, 2017

vi commented on Jun 5, 2017

Diggsey commented on Jun 5, 2017

vi commented on Jun 5, 2017

Diggsey commented on Jun 5, 2017

vi commented on Jun 6, 2017

alexreg commented on Sep 10, 2017

jyn514 commented on May 11, 2020

kinnison commented on May 11, 2020

vi commented on May 11, 2020

jyn514 commented on May 11, 2020

kinnison commented on May 12, 2020

Johnson9009 commented on Jun 20, 2020

rbtcollins commented on Jul 15, 2020

jyn514 commented on Jul 15, 2020

Johnson9009 commented on Jul 15, 2020

alexeymuranov commented on Jan 3, 2024

kinnison commented on Jan 3, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions