microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.23k stars 808 forks source link

WSL install hangs due to elevation issue #9032

Open benkehoe opened 1 year ago

benkehoe commented 1 year ago

Version

Microsoft Windows [Version 10.0.22621.674]

WSL Version

Kernel Version

N/A

Distro Version

N/A

Other Software

No response

Repro Steps

This occurred on a fresh machine, where I set it up with a primary user account that has a Microsoft account, which then is an admin. I then created a local user (as a regular user, not an administrator), and signed in as that local user (while leaving the admin session active as well), and ran wsl --install from PowerShell.

Expected Behavior

I should be able to install WSL, using the admin account to approve elevated permissions, staying logged in with the local account.

Actual Behavior

The command hung at the "Installing WSL..." message, without showing the progress bar. A prompt for elevating privileges appeared, which I approved using the admin account's credentials. The trouble was, there was a second elevation prompt for Windows Host Services that wasn't appearing there in the local account, only in the admin account's session when I switched back to it. Even approving there, and switching back to the local account session, the installation stopped hanging but said the elevation failed.

This was solved by making my local user an admin; approving the first elevation prompt with the local account's credentials then caused the second prompt to appear there as well and installation completed.

Diagnostic Logs

No response

Biswa96 commented 1 year ago

wsl --install command enables some core components of Windows OS with DISM APIs. It does require administrator privileges. Though you can enable WSL feature as admin and install Linux distributions in WSL as normal user (assuming that the install path has r/w permission to that user).

benkehoe commented 1 year ago

Right, I'm not expecting not to get prompted for elevated privileges, I'm expecting that the privilege elevation prompt happens in the session where I'm trying to install WSL. Or, that it simply fails. But what's happening is that a privilege escalation prompt is appearing in a different user's (the admin's) session, and no indication that this is happening is given in the session where the install is being attempted.

benhillis commented 1 year ago

@benkehoe - the second elevation prompt (and the problematic one) is one for "Host Process for Windows Services"? Right?

Is the behavior of wsl.exe --install different than something else that prompts for elevation, say regedit.exe?

benkehoe commented 1 year ago

Yes, that's the one, "Host Process for Windows Services". I have never seen or heard of an elevation prompt appearing in a different user's session for anything. Any tool that prompts multiple times, it's always in the same session as where the tool is running, even when using a different user's credentials to approve the escalation.

benhillis commented 1 year ago

Yah agreed, it's not ideal (the second prompt really shouldn't be needed). That one is coming from the app platform when installing the WSL msix package. We've filed a bug on them to not pop that dialog if the calling process is already elevated. I'll check on the status of that.

craiglandis commented 1 year ago

@benhillis any update on this? I hit it today because wsl --install runs as part of my bootstrap script for setting up a new PC. I kick off that script from elevated PS, but wsl --install still throws a Host Process for Windows Services UAC prompt. That blocks script execution since it's waiting for you to answer the UAC prompt (which it has no reason to be throwing since it's all running from elevated PS already).

This was on a fully patched Win11 22H2 22621.1265 install.

XcrigX commented 1 year ago

Any updates here? I am encountering this when running the install from the MS Store, from a non-elevated command prompt, and from an elevated command prompt. Problem is that it's a corporate machine and I do not have the credentials for the admin user the UAC prompt is for.

rmoreas commented 1 year ago

Any solution to avoid this UAC for "Host Process for Windows Services"?

We want to install WSL for our users using MECM (SCCM) but this UAC makes it impossible for users that do not have an admin account.

byjrack commented 1 year ago

Adding my name to the pile on trying to use "wsl --update" after WSL OS is installed and reboots completed, but the HPWS popup makes that a non-starter

byjrack commented 1 year ago

@benhillis is that bug on a public tracker we can link here? And if the process is not elevated is there a way to suppress that integration in the WSL MSIX? Guessing its to do with the systemd/init work?

byjrack commented 11 months ago

With the release of 2.0 in the Store I definitely got a storm of folks doing updates via the UI or via the command and all had the UAC issue which led to 80240066 errors when they had to cancel out.

The MSI release seems to be fine to run background, but we would much rather give the user the ability to use the existing channel.

Darkskittlz commented 9 months ago

I ran into this too. What worked for me after I determined I could install wsl from admin powershell was to install sudo on my non-elevated powershell and run sudo wsl --install

These were the steps I took.

Set the Execution policy as “RemoteSigned” and restrict its scope to only “CurrentUser”. This operation will permit the current user to run both local and downloaded scripts:

Step 1: Set Execution Policy Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Step 2: Install scoop irm get.scoop.sh | iex

Step 3: Install Sudo scoop install sudo

Step 4: Verify Sudo sudo

Step 5: Install WSL with Sudo sudo wsl --install

manelrodero commented 9 months ago

Any news on this UAC issue to be able to install WSL in the OSD process (with MDT, Config Manager, etc.)?

https://youtu.be/QgdMSswiS5o

Thanks.

byjrack commented 6 months ago

Do we think there will be a resolution for this? I had planned to offer the WSL installer in our Intune Company portal by publishing from the Store, but the UAC will drive too much call volume. The workaround continues to be to maintain the MSI install as a Win32 app installed as User, but far from ideal.

We are primarily 11 22h2 in case this has been resolved by KB in later releases of 11. If so knowing the KB may help us get this resolved quicker.

manelrodero commented 6 months ago

Hi @byjrack

We've solved this problem installing WSL2 during OSD (i.e. Features in the WIM + latest WSL2 MSI from GitHub).

And letting the user install his distro ONLY WHEN WSL has been provisioned to him (~15 minutes after first login).

We've explained this method in this Twitter thread: https://twitter.com/manelrodero/status/1760937740235932141.

Regards.

byjrack commented 6 months ago

Yeah thats not really an option for us given our demographic of users is a small slice of overall population so WSL (VMP, WSL OS, kernel, and WSL MSIX package) is always post-deploy. MSI based we are already rolling with in Company Portal without the UAC issue as a Win32 app that does it all. It just means the normal version chase though winget is helping there.

Preference though is to be able to use the Store copy via the CP/Store integration to lower that maintenance for the custom script.