`ElevationRequirement: elevationProhibited` appears to not be respected unless it's at the root level.

[stephengillie]

Brief description of your issue

• Noticed by @aisgbnok in Modify: Spotify.Spotify version 1.2.38.720.ga4a70a0e #155308:

Why does 910cce4 pass validation (comment), but 84484dc fail validation (comment)? The only difference being ElevationRequirement: elevationProhibited in the YAML root (pass) vs individual installer nodes (fail)?

• This is unexpected, because the 1.6.0 schema documentation has ElevationRequirement nested under Installers.

• Also impacted New version: Google.CloudSDK version 477.0.0 #154823

Steps to reproduce

• Have a manifest for a package which requires ElevationRequirement: elevationProhibited.
• Move that node from the root level to under the Installers level.

Expected behavior

The package manager would install the pacakge in a non-elevated way.

Actual behavior

The package manager attempts an elevated install, which fails.

Environment

#154823 (comment)

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

Windows: Windows.Desktop v10.0.19044.1288
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.22.11261.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                        Enabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Enabled

[Trenly]

Based on the behavior shown in the mentioned PR, the CLI is actually doing the right thing. This is indicated by the error being thrown by the CLI and not the Spotify Installer

2024-05-27 10:36:49.959 [CLI ] The installer cannot be run from an administrator context.

In this case, it's the validation pipelines that aren’t doing the right thing, so this issue should be moved to the winget-pkgs repo