WinGet Database getting corrupted on multi-user systems when using GSudo-like elevation methods

[marticliment]

Brief description of your issue

Assume the following conditions on a system are met:

• An administrator user (not the Administrator, but a regular user with administrator privileges)
• A standard user without administrator privileges, but that has the credentials for the administrator user
• GSudo or equivalent is installed on the system and added to path.

There are cases when WinGet will be executed as administrator with some tool like gsudo or similar in order to install/upgrade a package, and winget will get corrupted due to the lost of access to the %tmp%/WinGet folder.

This will break %temp%/WinGet directory permissions and cause the local user to not being able to use WinGet.

IMPORTANT: The issue can not be reproduced if the steps below are performed on an administrator command prompt (cmd.exe -> right-click -> run as administrator.) Window's sudo will not work, since the user is local. GSudo (or equivalent) must be used in order for the issue to be reproducable.

This issue is also reproducible using UniGetUI and upgrading a package via the built-in "Upgrade as administrator" option, which relies on UniGetUI Elevator to elevate WinGet (which is essentialy a custom build of GSudo)

Relevant issues posted on marticliment/UniGetUI, that are caused by this corruption:

• [BUG] UnigetUI keep asking me to repair Winget, then Winget is properly installed and working (just not with UnigetUI marticliment/UniGetUI#3087
• [BUG] "WinGet-Error detected. Do you want to repair WinGet?" marticliment/UniGetUI#3153
• and many others

Steps to reproduce

1. Log in into a local, non-admin account.
2. Open a **non-**administrative command prompt
3. Run winget update. Everything works fine.
   Now, there is a WinGet subfolder under %temp%, whose owner is the current user. (as expected).
4. Upgrade a package elevating WinGet via GSudo. For example gsudo winget upgrade Google.Chrome.Exe. Enter the administrator credentials and click yes
5. The upgrade proceeds as expected.
6. Run winget upgrade again. See the following error:

Error while trying to update source: winget
Error while opening the predefined source: Please report this problem to the winget developers.
0x80070005 : unknown error

7. Now WinGet can't be used. Neither from CLI nor from COM APIs (apps like UniGetUI will show COMException when trying to connect to WinGet) can interact nor retrieve data from WinGet.
   On the local user's %temp%, the WinGet subfolder is now owned by the administrator account. the local user cannot read nor modify the contents of the %temp%/WinGet directory. Furthermore, the command gsudo winget upgrade works as expected. Deleting the temp folder can solve the issue.

Expected behavior

WinGet should detect that it has been elevated, and should use the administrator's account temporary folder, or at least be less restrictive with the permissions of the temp folder.

Actual behavior

WinGet cannot be used anymore unless the temp folder is reset.

Environment

Windows Package Manager (Preview) v1.10.40-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.26100.2605
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.25.40.0

Winget Directories
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag…
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett…
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

[marticliment]

I have found out that, if prior to calling gsudo winget.exe ... the environment variables %TEMP% and %TMP% are overriden on the same command prompt, WinGet will store temp files on this new folder, and not modify the original %temp%\WinGet folder, keeping the ACLs intact.

[TyrrellStephen]

I have found that by specifying the username of an administrative user (local in my case) in gsudo, the temporary file paths are changed to that of the specified user. This approach works in PowerShell (5.1 and 7.5) for interactive and non-interactive sessions, in both new and existing windows.

# PowerShell - works:

# 1
PS C:\Users\StdUsr> gsudo --user ADMIN "`$env:TEMP"
Password for user COMPUTER\ADMIN: ***************************
C:\Users\ADMIN\AppData\Local\Temp

# 2
PS C:\Users\StdUsr> gsudo --user ADMIN
Password for user COMPUTER\ADMIN: ***************************
PS C:\Users\ADMIN> $env:temp
C:\Users\ADMIN\AppData\Local\Temp

# 3
PS C:\Users\StdUsr> gsudo --user ADMIN --new
Password for user COMPUTER\ADMIN: ***************************
# new window...
PS C:\Users\StdUsr> $env:temp
C:\Users\ADMIN\AppData\Local\Temp

# PowerShell - not working

# 4
PS C:\Users\StdUsr> gsudo "`$env:TEMP"
C:\Users\StdUsr\AppData\Local\Temp

# 5
PS C:\Users\StdUsr> gsudo
PS C:\Users\StdUsr> $env:temp
C:\Users\StdUsr\AppData\Local\Temp

# 6
PS C:\Users\StdUsr> gsudo --new
# new window
PS C:\Users\StdUsr> $env:temp
C:\Users\StdUsr\AppData\Local\Temp

However, with CMD specifying the username only works with the approach only works for interactive sessions.

# CMD working:

#1
C:\Users\StdUsr> gsudo --user ADMIN
Password for user COMPUTER\ADMIN: ***************************
C:\Users\StdUsr# echo %TEMP%
C:\Users\ADMIN\AppData\Local\Temp

#2
C:\Users\StdUsr> gsudo --user ADMIN --new
Password for user COMPUTER\ADMIN: ***************************
# new window...
C:\Users\StdUsr# echo %temp%
C:\Users\ADMIN\AppData\Local\Temp

# CMD - not working

# 3
C:\Users\StdUsr> gsudo --user ADMIN "echo %TEMP%"
Password for user COMPUTER\ADMIN: ***************************
C:\Users\StdUsr\AppData\Local\Temp

# 4
C:\Users\StdUsr> gsudo "echo %TEMP%"
C:\Users\StdUsr\AppData\Local\Temp

# 5
C:\Users\StdUsr> gsudo
C:\Users\StdUsr# echo %temp%
C:\Users\StdUsr\AppData\Local\Temp

# 6
C:\Users\StdUsr> gsudo --new
# new window...
C:\Users\StdUsr# echo %temp%
C:\Users\StdUsr\AppData\Local\Temp

I think that this looks more like a problem with gsudo than winget.

[marticliment]

I think that this looks more like a problem with gsudo than winget.

What happens is that GSudo passes the environment variables from the original process (which are the regular user's), and WinGet pulls the temporary folder from the ENV variables. What I reckon the issue is, is that WinGet is properly detecting that it is running as a different user (since the ACLs are correctly set), but is failing to obtain the correct temp folder for the new user, and it uses the one set on %TEMP%. Perhaps WinGet could pull the temp folder location from a different source (perhaps from the windows registry) so this issue doesn't happen.