winget settings --enable LocalManifestFiles does not work when admin is separate user

[raphael-zenhaeusern-legic]

Brief description of your issue

In order to use local manifests, functionality first has to be enabled with winget settings --enable LocalManifestFiles. If the user is not an admin, winget will return This command requires administrator privileges to execute. which is expected. But when running the command in an administrator context, it has no effect on the non-admin user. Probably due to separated installations for admin and non-admin?

Steps to reproduce

• have two (2) users, admin A and non-admin B
• Run terminal as A and execute winget settings --enable LocalManifestFiles
• Run terminal as B and attempt to install a local manifest file winget install --manifest C:\Path\To\Manifest

Expected behavior

This setting should either be shared across users or winget starting a dynamic elevation so the user can proof he has admin access to the machine.

Actual behavior

It is not possible to enable local manifest files for a non-admin user.

Environment

Windows Package Manager v1.4.10173
Windows: Windows.Desktop v10.0.22621.1555
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.10173.0

[denelon]

WinGet is delivered via the App Installer which is an MSIX based package and has specific isolation boundaries. If user A has administrative rights, then they are allowed to modify the administrative settings in WinGet for their account. If user B does not have administrative rights (or access to them) then they are not allowed to modify the administrative settings in WinGet for their account.

If the administrative settings need to be modified for user B, then it's most likely better to leverage the Group Policy Objects to modify the settings for the system.

Can you help me understand the scenario a bit better if this is a feature request?

[raphael-zenhaeusern-legic]

Seems like I left out some information to the use-case, please excuse.

The relevant point is that user A and B, while distinct Windows users, are (usually) the same person. So, while the person is generally authorized to perform tasks that require admin privileges, they normally run their computer with an unprivileged user B. Whenever something needs admin, they enter the credentials from user A. This is commonly referred to as a "localadmin".

This setup with a separate admin account aims to adhere to the principle of least privilege and is in accordance with Microsofts own recommendations (see for example https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models#on-workstations). It is actually quite a common setup with enterprises.

Now I understand this is something the design of winget did not have in mind as is evident by issues like #2740 that occur with exactly the same setup for similar reasons.
But it would be great if this scenario and its consequences could be considered in the future (and this issue could be addressed).

[denelon]

Thanks. That additional context helps.

We've been doing some work for system context recently. We've also started to update manifests where a UAC gets triggered for packages installed in user context. We're using "elevatesSelf" as the value to give WinGet the proper hint. The primary use case we've seen driving this is typically the result of a package that is going to install machine wide. It seems this would work for the scenario where user B could take the action and user A would see the desired outcome of the package being installed machine wide.

This scenario is quite a bit different though. I think we would still have the concern regarding isolation of privilege. We wouldn't want to introduce a situation where some other user C who shouldn't have the ability to run using local manifests is inadvertently granted that permission.

What is the reason the account for user A wouldn't be the one used to install a package with a local manifest?

[raphael-zenhaeusern-legic]

The main scenario I personally encountered where admin user A wouldn't be the one used to install with a local manifest are user scoped apps.
This is true for both just restricted in-house apps but also when building a manifest for the public winget repo and wanting to validate it.

[treysis]

Same problem applies generally when trying to set administrative options, e.g. InstallerHashOverride. My user is a local user without admin, set by Active Directory Group Policy. However, this user should be able to override hash mismatches sometimes. This isn't a security risk as overriding the hash doesn't mean the user is granted administrative privileges for installing applications. Applications will still install in user context.

However, since this local user can't elevate itself but has to use an admin account for privileged actions, this doesn't work. The admin account can't set those "protected" options for another account. This is really annoying in multi-user environments and we just CAN'T give every user administrative privileges but we would want them to be able to use the full potential of winget.

I've raised this issue in #3543 when I didn't understand the exact cause correctly. Now I do, though.

[KiruyaMomochi]

To use the Group Policy Objects for non domain-joined computers:

1. Download group policies from Microsoft Download Center
   https://www.microsoft.com/en-us/download/details.aspx?id=103034
2. Extract the archive and copy these files into C:\Windows\PolicyDefinitions
3. Open group policy editor gpedit.msc as admin, go to Computer Configuration > Administrative Templates > Windows Components > Desktop App Installer and modify settings there.

Reference: Use Group Policy ADMX files in Windows 7 or 8 (non-domain computers) | @Poremsky.com