[WINDOWS] Auto elevate

[deeprobin]

Describe the problem you are trying to solve

I want to auto-elevate rustup, if it needs administrator permissions on windows

Describe the solution you'd like

Windows has a runas command

[kinnison]

rustup is meant to be installed per-user, not system-wide. As such, elevation shouldn't be necessary since rustup should never run with administrator privileges.

What is your use-case for suggesting this?

[deeprobin]

@kinnison I installed rustup on a drive root dir to save drive usage.

[kinnison]

So this is a multi-user system and you want to share a rustup installation between users?

[deeprobin]

Yes.

[kinnison]

This is a model we've not considered before, so we'd need to think through a lot of the consequences of this before jumping to any conclusions.

Firstly, user A could be surprised by the compiler changing underneath them. By this I mean, if user A ran a build, then left the system. user B came along and decided to run rustup update nightly for example, and then user B left. User A came back and then tried to build a small change to their program only to discover that the compiler changed underneath them and now their code doesn't build.

Secondly, user A could be relying on a particular component in a channel which user B decides to remove. User B might be relying explicitly on the absence of that component, and so the users enter a battle where one adds a component and the other removes it, over and over again.

Thirdly, user A adds a toolchain via rustup toolchain link but it's to a location user B cannot read. Now there's a dead toolchain visible to user B which they can do nothing about.

I'm sure I can come up with other examples of how multiuser setups for rustup might cause problems. The task we now have to undertake is to decide what the right resolution of the problem is in each case, and what that means in terms of effort to implement in rustup.

When we have a reasonable idea of what it might take to support multiuser rustup installations safely, consistently, and predictably, then we can discuss auto-elevation to deal with that.

[DJMcNab]

For me, in the past I've used multiple windows users, all for myself. In this case, this was before I found the git includeIf config, so I needed to support multiple git identities, and multiple windows users was the best way for me. But in this configuration, I have rustup at C:/Programs/Rustup, which doesn't need administrator priveleges.

[workingjubilee]

@rustbot label: +O-windows

[rbtcollins]

there are multiple of issues here: to update in-use programs requires shutting down running instances of programs; CARGO_HOME is presumed writable, and Rustup writes to CARGO_HOME. Rustup has on-demand installation of toolchains so would need all users to be able to elevate on-demand, kill off all running users processes even if the user was not active (because of Terminal Services) and then continue.

Not saying its not possible, but its a very different use case to 'get a developer environment working'.

I'm happy to help design a robust minimal-emergent complexity system for this, but I'm not interested in implementing it: disk space is cheap on all Windows machines capable of compiling Rust these days compared to the size of a Rust toolchain and the vastly bigger Rust build products and crate build cache. If someone wants to implement this, then sure.