No UAC prompt

[brunovieira97]

Description of the new feature/enhancement

Don't show a UAC prompt if installation of software is being done through WinGet. Much like as it's possible with Scoop.

[Stanzilla]

That only works because scoop does not install to Program Files

[dhrrgn]

This seems like it would create some security nightmares. Since the install commands can be ran from a script, it would be fairly simple to exploit that. Maybe if they added a flag, that somehow only worked when ran directly from the shell...but even that could be worked around in all likelihood.

[JoBrad]

Scoop does this perfectly, actually. It installs the portable version of the apps, and uses symlinks to point to the current version, your app config, and a common bin folder. So you don’t have to add as many paths to your PATH variable (you still do, but not as often).

[Nowaker]

That only works because scoop does not install to Program Files

Great idea, let's NOT install to Program Files!

[tresf]

This seems like it would create some security nightmares

As others have indicated, it's not a security issue, the apps are coerced to install to user space through various methods (Portable apps or 7zip extraction combined with manual user-space registration, etc).

[Calinou]

For the record, Electron apps' installers will often install to %LOCALAPPDATA% to avoid UAC prompts. That path is generally considered the standard location for user-wide program installation.

I'd be surprised if Microsoft changes the default path to an user-wide location, but maybe an --user option can be added to install applications on an user-wide basis. This is what Flatpak does, for instance.

[gerardog]

I think we all agree "No UAC prompt" does not work for system-wide installs. If it affects other users, elevation is required.

So, "no UAC" only works for current-user-only installs. But does WinGet install to current-user or does system-wide installs?
Correct me if I am wrong, but I think it actually depends on the app manifest that WinGet just executes. I wasn't even able to find documentation about how your app should be packaged for user/system scenarios. So was this planned? Or MS just let each app installer to behave differently? This looks messy.

Of course it should have --user / --system flags.

I propose this and #271 are closed in favor of a System install VS User Install mode. Which just found out is already /dupe #281

[brunovieira97]

I believe that the best approach would be user-only installs by default, with a --global npm-like switch, so we can install that particular app system-wide. Once again, Scoop does exactly this.

The most important thing is consistency. There must be a default behavior that every manifest installation shall follow, and a switch or parameter so we can specify a different one.

[dmex]

the best approach would be user-only installs by default

User-only installations create security issues with binary planting/hijacking attacks. It could be an optional feature but most definitely not the default option.

[brunovieira97]

User-only installations create security issues with binary planting/hijacking attacks.

I highly doubt this is a security concern for the everyday user. If so, various apps that are currently installed on user level (such as VS Code) would never be advised as so by Microsoft. The main users of package managers will, undoubtedly, be developers.

UAC at every install is a workflow-killer, needing additional interaction when I'm already passing a full command on my terminal with (what should be considered as) all needed information for installing a particular software.

[dmex]

various apps that are currently installed on user level (such as VS Code) would never be advised as so by Microsoft.

vscode doesn't install a kernel driver like the itunes, hwmonitor, cpuz, nmap and other current winget packages do currently and so the attack vectors when executing vscode from user writable folders are limited in comparison to executing kernel driver/applications from user writable folders.

If winget auto-elevated the package installations an attacker will execute winget to install vulnerable versions of a package and exploit the automatically installed kernel driver to elevate privileges to administrator and compromise the machine and use those administrative credentials to compromise the entire corporate network - lateral movement with PsExec launching winget.

UAC at every install is a workflow-killer, needing additional interaction when I'm already passing a full command on my terminal

You're always going to see a prompt unless you disable UAC.

It is possible for winget packages to include a "requires admin" flag and before installation winget prompt to elevate itself and continue the installations for those packages as administrator. This would negate the attack vector from automatic elevation and reduce multiple prompts to a single prompt but you would still see the one prompt and winget would need to allow installing multiple packages with one command.

[tresf]

install a kernel driver like the itunes, hwmonitor, cpuz, nmap and other current winget packages

I feel like this project is trying to be both a deployment tool and a package manager at the same time and these arguments won't ever end.

The user-space installs are recommended for those that can be installed in user space. Perhaps the compromise is for Windows to add a sudo-like command to the OS (not runas) but to make claim user-scope-by-default is bad seems short sighted. The security is improved when kernel-mode drivers take a back seat to the apps that don't need this type of access. Lowest privilege is often preferred for security reasons. If this tool only aims to be a wrapper around the Windows store, no one except Windows administrators will use it. The audience for this type of tool is much larger if done correctly.

Just setting up cmake, maven or ant is tedious on Windows. These types of things don't need UAC or administrator access to be installed yet are available in every package manager (brew, apt, pacman). Heck, even Solaris can install them.

[aetos382]

Winget should not (as scoop does) extract files from installer packages (such as exe or msi) and place them in user space in such a way that the application provider does not support them, to avoid UAC prompts.

[tresf]

Winget should not

Is this opinion? If so, please make that clear. If winget has no intention to add a UAC-less installation technique, it needs to be stated by the project maintainers as fact so people looking to leverage it for such use-cases can unsubscribe from the repository.

Anyone coming here from an automated/CI/dev perspective to the likes of AppVeyor know that there's a huge missing package manager for common tools on Windows. To blindly state that it should never work in user-space reads more like opinion than fact. A technique which works without UAC is needed, this issue is evidence of that. If winget has no intention of adding UAC-less operation, perhaps it will just increase the popularity of Scoop and those needing it can unsubscribe here, head over there, but I'd rather read that as fact so that devs needing it can decide whether or not to continue following this project.

[tresf]

and place them in user space in such a way that the application provider does not support them

Anyone that's used Homebrew knows that most tools are portable by nature. Scoop takes advantage of this. The fact that it extracts the installers and sets them up manually (using unconventional means) is just a limitation of Windows culture, not a technological limitation. The narrative should be welcoming of this. The culture needs to be accepting as a whole regardless of what's currently "supported". The entire Homebrew project exists because developers decided to port tools over to Mac where they weren't necessarily supported or welcome. Now, Homebrew is the gold standard for package management on macOS. If that's what this project aims to be on Windows, the dialog needs to be accepting of this -- at least on principal.

[aetos382]

Is this opinion? If so, please make that clear.

Yes, it's my opinion, and I'm not winget maintainer.

I would prefer that the tool can be installed without UAC.
I believe that to increase such tools, we should first encourage the authors of the tools to support such a form of installation.

If a third party publishes a manifest that extracts files in a way that the tool's author does not officially support, it should be made clear that the author of that manifest is responsible for supporting it.

Scoop uses ’msiexec /a’ command to extract files from the MSI package, but this command is intended to create an administrative installation point, not to run the extracted files directly.

I think Microsoft should not endorse the use of such a file extraction method for other purposes just to get around UAC.

[tresf]

I think Microsoft should not endorse the use of such a file extraction method for other purposes just to get around UAC.

Beating a dead horse, but it's Microsoft's historical culture of requiring desktop installers to begin with that's resulted in this mess. Yes, manual relocation is putting the cart before the horse (so to speak), but meanwhile reverting 25 years of desktop installers takes time. For example, as a software publisher, I have absolutely no intention on ever offering an MSI, but that doesn't mean my apps aren't relocatable. It doesn't mean support suddenly vanishes once they're moved. Some apps have to register hundreds of PC settings on install -- which can be argued -- is a can of worms. Others, such as Python, Java, CMake are often fine setting the user's PATH and a standardized lib/import location, something that's not uncommon in the POSIX world, something people have been hoping for on Windows for a long time.

[AvivNaaman]

Feel like I can add something to this discussion.

Environment

Lab of ~25 PCs, running Win10 v20H1, with more then enough memory, disk space and CPU power. All connected to AD DS, and there are no admin privileges for any user who use these machines on a daily basis (though, logged using my IT administrator account which is a duplicate of the AD Administrator account). UAC on, normal level. All have Veyon installed, and configured to work with the AD DS. All the PCs have the same software installed.

Installation

I installed winget using the Appx package, directly using powershell with the Add-AppxProvisionedPackage cmdlet, ran it using elevated PS on each machine using the "usual" machine user account. The installation was fine and I was able to run the winget.exe list command successfully on ALL the machines.

Elevation problem

Afterwards, I selected all the packages that I wanted to update (or - actually upgrade in this context), about 7 packages. I wrote a short, nice script with many calls to winget.exe upgrade <Package> - for each package (another nice feature to have: updating multiple packages at once like apt...). Then, WinGet (or actually, the installers) requested elevation for each and every program installation. Then i rewrote the script to be a self-elevating PS script (to self elevate and nothing more - everything else was just calling the winget.exe upgrade <Package> command), and the winget command was not even 'identified' (yeah, I know, not in path of the elevated user) - and I couldn't fix it remotely.

Conclusion

I think it'll be great to just have the option to elevate the winget command (for example - using an argument or something), or at least installing it globally to allow all the users to access the executable WITHOUT logging in to the user's ad account in the desktop experience.

Thanks!