NTFS permissions for the -d switch follow the parent, but should be set to the destination

Relevant area(s)

WinGet CLI

Relevant command(s)

winget download

Brief description of your issue

If you use the -D switch with WINGET DOWNLOAD to specify a custom folder to save the file into,
the NTFS permissions are set as the user who ran the Command Prompt window, not the permissions
of the destination folder.

This leaves some users unable to execute, copy, move or delete the files.

Steps to reproduce

1. In the admin account on your PC, run a Command Prompt window (as that user: not via "run as Administrator")
2. Download an app into a different user's account, in my case:
   winget download SumatraPDF.SumatraPDF -d "C:\Users\dftf\Downloads\Winget"
3. Log off the admin account, and in as that user
4. Locate the file and note there is only a generic icon for it
5. Right-click the file and go to "Properties", then the "Security" tab. It will read:
   You must have Read permissions to view the properties of this object. Click Advanced to continue

You can also put the command in Step 2 into a .BAT file, then run that "as administrator" from within the user account to create the same issue

Expected behavior

WINGET should set the NTFS permissions to match the destination folder, not the user who ran the process

Actual behavior

WINGET sets the following permissions on the downloaded file:

Owner: ADMIN1 (EXAMPLEPCNAME\ADMIN1)

Permission entries:
Type Principal Access Inherited from
Allow ADMIN1 Full control C:\Users\dftf
Allow Administrators Full control C:\Users\dftf
Allow SYSTEM Full control C:\Users\dftf

This means user "dftf" cannot rename, delete, execute, move or copy the file

Environment

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

Windows: Windows.Desktop v10.0.19045.7058
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.28.220.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
Configuration Modules              %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules

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

Start with the winget download command's destination handling and the code that creates or saves the downloaded file; the issue does not identify a file or test. Reproduce the admin-to-other-user scenario, inspect the resulting NTFS permissions, and add coverage showing that the downloaded file matches the destination folder's permissions.