Chocolatey GUI doesn't elevate with a standard Windows user account

[RiseT]

Currently, when launching ChocolateyGUI v0.15.0 on a standard Windows user account (non-admin), there's no UAC password prompt, i. e. it doesn't ask for elevation.

Consequently, when trying to install, update or uninstall a package with ChocolateyGUI, it fails as of missing privileges.

As a convenient solution, rather than solving this by elevating when launching ChocolateyGUI, I suggest not elevating until the moment the user issues a command that needs elevation (e. g. the Update All button) for the first time for that session.

That way, the user can still e. g. check if there are any app/package updates without getting the UAC prompt and having to enter the admin password each time.

Currently, I'm often launching ChocolateyGUI without admin privileges in order to check if there are any package updates, and if this is the case, I quit ChocolateyGUI an re-start it via right clicking and "Run as administrator".

Here's an example of what I mean (i. e. the type of button or context menu command):

[RichiCoder1]

You don't realize it, but you've stumbled on one of the longest fought issues on Gui :). /cc @gep13
We did actually sort of do what you suggest previously, but we reverted to runAsInvoker for the 0.16 release. We might switch back to a scheme like this moving forward.

[gep13]

As @RichiCoder1 said, this is a long, drawn out discussion. In the run up to the last release, we did have something similar to what you have shown, but in the spirit of simplicity, we took it out again. Coupled with the fact that Chocolatey has a self service mode, where a non admin can do the installation as well, it was felt that this was a better fit for now.

[RiseT]

Coupled with the fact that Chocolatey has a self service mode, where a non admin can do the installation as well

It looks like this is for the Business Edition only...? Is this correct? I'm a private user using a non-admin account for enhanced security.

[gep13]

@RiseT said...
It looks like this is for the Business Edition only...? Is this correct?

That is correct. We are trying to make Chocolatey GUI work in the best way possible, while catering to all use cases.

[ferventcoder]

Hi @RiseT - we set the execution privilege to highestAvailable -

ChocolateyGUI/Source/ChocolateyGui/app.manifest

Line 25 in 31f8544

<requestedExecutionLevel level="highestAvailable" uiAccess="false" />

This means if your account is a non-administrator it won't ask for UAC. If your account is an administrator, it will ask for administrative permissions on startup.

I'm not even sure we had things set up the way you are describing when we were looking at a much more complex route to asserting UAC at runtime (complete non-admin, having admin credentials pop for run as).

[ferventcoder]

Related to

• Execution Level - Prefer highestAvailable over requireAdministrator #342 / Use highestAvailable instead of subprocess #465
• [WIP] Add Chocolatey Subprocess #347 / Refactor Subprocess Structure #438

Subprocess issues:

• Random Chocolatey GUI crash #448
• NullRefEx on launch #440
• Chocolatey GUI errors on subprocess when attempting to open more than one instance of Chocolatey GUI #372
• Debugging code became quite difficult
• Missing WCF data contracts in properties could produce hard to find bugs

[ferventcoder]

Perhaps there may be an opportunity to approach this again in the future. Currently after a 9 month dive down a rabbit hole, the scars are maybe too fresh to approach this.

However if I understand your approach correctly, you are looking for more the UAC into a totally different user (aka "Run As"). If there is something that could easily support that and still have things be very debuggable, I'm guessing we might approach that use case. The administrator with UAC will get elevated when starting Chocolatey GUI and I think we are fine with that scenario for now.

[RiseT]

However if I understand your approach correctly, you are looking for more the UAC into a totally different user (aka "Run As").

Example:
I have 2 user accounts on my Windows machine. One is called "Admin" (administrative privileges, only used for installing software or other tasks that require admin privileges), the other one is called "Daily Work" (no admin privileges, used as my primary account for browsing, office, etc).

Currently, when I run ChocolateyGUI from the user account "Daily Work", every package installation, etc will fail without prompting for the password of the user account "Admin" and without elevating privileges.

Of course, using "Run as administrator" in the context menu of ChocolateyGUI prevents this.

But in ChoclateyGUI, a) a non-admin user should have a possibility to check if there are package updates available, and b) if that user discovers that there are indeed updates available, there should be a way to elevate (via entering a password) & upgrade without having to exit and restart ChocolateyGUI.

[ferventcoder]

@RiseT yes, that's exactly where I thought you were going. I am not even sure if the subprocess bits we had implemented wrapped this scenario or not. This would be something we can strive for eventually. It's unfortunately not as straightforward to implement as one might hope.

[RichiCoder1]

@ferventcoder Yup, the subprocess did that. The issue was mostly A) we piped everything to the subprocess, even if it didn't require privileges and B) the subprocess was very fault intolerant and the RPC was kinda hacky.

[RiseT]

There's a related issue for this scenario (using Chocolatey with a standard/non-admin user account), although that might be a problem of Chocolatey itself rather than Chocolatey GUI:

The installer of some applications installs them on a per-user basis (e. g. in "Users\Username\AppData").

Since - when using a non-admin user account - Chocolatey always needs to elevate to an account that does have admin privileges, the result is an installation of that application in "Users\Admin\AppData") rather than in "Users\Non-Admin\AppData"). Thus, the application cannot get accessed/used by user "Non-Admin".

[mtnielsen]

The fix should be very simple no?

if Run as admin 
    Business as usual.
if Not run as admin
    if Self-service exists 
        Send command to self-service
    Else
        Fail gracefully