winget command incorrectly resets permissions on the %TEMP%\winget folder

[Hermholtz]

Brief description of your issue

Every time winget is downloading an installer package into %TEMP%\winget, it resets security descriptors on that folder to only include currently logged-on user and the SYSTEM account, and it disables inheritance of permissions from %TEMP%.

The issue is impacting non-admin users who need to elevate to a different account which has administrator permissions in order to install/upgrade software.

winget should just create the %TEMP%\winget directory with inherited permissions, assuming that they have been set properly on %TEMP% or above, and don't manipulate them.

Steps to reproduce

1. Create a non-admin account in Windows (only belonging to "Users" group), for example "Hermholtz".
2. Create an admin account (member of "Administrators" group), for example "HermholtzAdm".
3. Log in as the admin user and set up access to the non-admin profile, i.e. add "HermholtzAdm" as "Full access" to C:\Users\Hermholtz. It will be propagated to all files and folders. This will grant HermholtzAdm permissions to access Hermholtz's %TEMP% folder.
4. Login as the non-admin user.
5. Have an outdated software installed that can be detected by "winget upgrade" command., for example an older version of Paint.NET.
6. As the non-admin user try "winget upgrade paint.net". It will display UAC prompt, enter credentials of the admin account.
7. Observe the Paint.NET installer uninstalling the previous version and then failing with error 1603.
8. Open Windows Explorer, go to %TEMP%, open the properties of "winget" folder, observe that only the non-admin user and SYSTEM account are present, and inheritance is disabled.

Expected behavior

winget doesn't modify the security of %TEMP%\winget folder, which would allow for seamless upgrade of packages requiring elevation to a different admin account.

Actual behavior

The admin user cannot access the %TEMP%\winget folder of the non-admin account because of the permission problem. Therefore software requiring elevation to install cannot access the installer file and fails to install.

Environment

Windows Package Manager v1.4.11071
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19045.3031
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.11071.0

[JohnMcPMS]

You will be happy to learn that this problem should already be resolved in the upcoming 1.5 release (fixed by #2945). While it isn't resolved exactly as you have described, it should work for the scenario you have presented.

You can give it a try by installing the release candidate for 1.5: https://github.com/microsoft/winget-cli/releases/tag/v1.5.1572

[Hermholtz]

Thank you, indeed winget 1.5 so far works fine. So I think this issue can be closed then.