You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Run winget update. Everything works fine.
Now, there is a WinGet subfolder under %temp%, whose owner is the current user. (as expected).
Upgrade a package elevating WinGet via GSudo. For example gsudo winget upgrade Google.Chrome.Exe. Enter the administrator credentials and click yes
The upgrade proceeds as expected.
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
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
The text was updated successfully, but these errors were encountered:
Brief description of your issue
Assume the following conditions on a system are met:
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
winget update
. Everything works fine.Now, there is a WinGet subfolder under %temp%, whose owner is the current user. (as expected).
gsudo winget upgrade Google.Chrome.Exe
. Enter the administrator credentials and click yeswinget upgrade
again. See the following error: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 commandgsudo 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
The text was updated successfully, but these errors were encountered: