Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
marticliment opened this issue Jan 5, 2025 · 0 comments
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation.

Comments

@marticliment
Copy link

marticliment commented Jan 5, 2025

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:

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
  1. 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation.
Projects
None yet
Development

No branches or pull requests

2 participants