Please elevate session, or spawn elevated session as necessary.

[sharpninja]

I cannot express how frustrating it is to be working in a normal powershell session and then need to install something via cinst only to get a security exception. Please elevate the session when necessary with RunAs or Invoke-Command -Verb when necessary.

[bcurran3]

Try https://chocolatey.org/packages/gsudo

I'm digging it.

There's others, sudo, elevate, etc.

[sharpninja]

This is a fundamental problem with choco, installers have invoked uac elevation on their own since Vista came out, it's expected behavior.

[AdmiringWorm]

installers have invoked uac elevation on their own since Vista came out

That is not entirely true, yes it may look that way to an end-user, but in general, installers don't invoke the UAC on their own.
Typically installers have an embedded manifest file that tells windows always to request administrator privileges, but they do not elevate themself (a minority of installers do self-invoke though).
This unfortunately, isn't something that could be done with chocolatey that easily, as there are more nuances to when the elevation needs to happen.

So, then the question becomes, when should chocolatey self-invoke the UAC (remember that it needs to spawn a new process of itself, possibly running the same code again, and can't use the typical manifest file).

Some places would be

1. If chocolatey is installed to the default directory, all transaction commands should be elevated (for install, uninstall, update, etc).
2. When updating the configuration file
3. When needing to delete a previous version of the chocolatey executable (again, if the program is installed to the default directory).
4. If chocolatey is installed to a non-default directory, self-elevation would only need to happen when it tries to run an installer that requires admin rights (normal self-elevation as point 1 shouldn't be done here, as this would cause issues for users not being able to run chocolatey as admin and only rely on portable packages).
5. If a package is incorrectly (in my opinion), extracting an archive to the Program Files directory (or other admin locked write locations).

Those are just a few points that I remember from the top of my head, and there certainly are many other scenarios that self-elevating would need to happen.

[sharpninja]

yes it may look that way to an end-user

That's because it's the correct behavior from the end user perspective

If chocolatey is installed to a non-default directory

This should be the default behavior. Installing to a non-default location is not well documented nor a trivial task.

[AdmiringWorm]

That's because it's the correct behavior from the end user perspective

In the case of installers, yes. But not in all situations.

This should be the default behavior.

No, it really shouldn't as this would also mean it would force the elevation in cases where it shouldn't be elevated as well (otherwise, we could just get rid of the UAC and go back to Windows XP, as it would be basically the same thing).
However, chocolatey should elevate itself when it is necessary to do so (I am just trying to point out that it isn't as trivial as you may think).

Installing to a non-default location is not well documented nor a trivial task.

On the contrary, it is very well documented here: https://chocolatey.org/docs/installation#installing-to-a-different-location and is as easy as setting 1 environment variable before doing a normal install of chocolatey (securing the directory is a completely different matter).

[sharpninja]

There is no indication to the uninitiated of the implications of the default install location nor is it clear that you can even install to an alternat location as that info is buried as the eleventh link under More Options and doesn't appear in either sidebar.

[ferventcoder]

nor is it clear that you can even install to an alternate location as that info is buried as the eleventh link under More Options and doesn't appear in either sidebar.

@sharpninja I'm going to respectfully disagree here - you typically start at https://chocolatey.org/install (that is where the site points you to from front page, top-level navigation, etc). Now you'll notice on step number 1, we make mention of that immediately and include a link to non-administrative install. Here's an image of that:

[ferventcoder]

This should be the default behavior. Installing to a non-default location is not well documented nor a trivial task.

I'm going to respectfully disagree on the premise of a "secure by default" design. If you choose to install to a non-default location, you are choosing to lower security posture and open up a potential of running scripts or apps that can be changed by a non-administrator. That's bad IMHO. Some people want that and I get it, but it's just not going to be the default as it is insecure. More on this at https://chocolatey.org/docs/security#what-about-a-non-administrative-installation-of-chocolatey-is-it-secure .

[ferventcoder]

There is no indication to the uninitiated of the implications of the default install location

@sharpninja can you elaborate on what you would like to see as far as this goes?

[ferventcoder]

This is a fundamental problem with choco, installers have invoked uac elevation on their own since Vista came out, it's expected behavior.

If Chocolatey merely ran installers, I would be right there with you. However, that is not what it does - or rather just a tiny portion of what it can potentially do. Chocolatey manages Chocolatey packages, and a package (nupkg file) can contain scripts, binaries, files, zips, and yes, it can container and manage installers as well.

[ferventcoder]

All of those scripts and other things need to be secure to remove the potential that something without administrative rights, could affect the files, etc, prior to an administrative scenario actually executing those things. Security ruins all the fun, I know.

[sharpninja]

@ferventcoder - Look at it from this perspective. Using choco as my package manager means I'm normally running an admin powershell session so I can install stuff as needed without constant interruption to spawn a new admin powershell window manually, install my app, then close my original powershell window and reopen it so the new app shows up on the path. There's a lot more risk to that than someone getting a malicious script from choco.

[sharpninja]

There is no indication to the uninitiated of the implications of the default install location

@sharpninja can you elaborate on what you would like to see as far as this goes?

If you're new to choco, especially if you've used package managers on other platforms, the first 10 times you have to spawn a new admin PS session to run choco successfully, followed by figuring out your new app isn't on the path of the original session, and that you then need to close and re-open your original session to get the new app to work, will undoubtedly lead to a mild level of rage (as it still does for me, many years and installs later). Defaulting to installing to $env:userprofile/.choco or something can still trigger UAC as necessary but avoid it altogether for portable apps. As for scripts in packages, the user's script policy should be responsible for that.

[sharpninja]

@sharpninja I'm going to respectfully disagree here - you typically start at https://chocolatey.org/install (that is where the site points you to from front page, top-level navigation, etc). Now you'll notice on step number 1, we make mention of that immediately and include a link to non-administrative install.

There is a big difference between a non-administrative install and an end-user install. The former implies you don't need to elevate to run it, the latter implies installing under $env:userprofile. The link takes you to this hot mess:

This basically says "You shouldn't do this" and "We have over 200 packages supporting this" in the same paragraph. Confusing any? Also, it links the instructions for non-standard location which says:

This is due to alternative locations could have a range of permissions that should not be changed.

OK, but what does that have to do with choco creating a default location such as $env:userprofile/.choco and applying the appropriate security on that folder to support non-admin installs? All it does is confuse the user and reiterate that choco should only be run by admins.

Which all reinforces my original request. Simply have choco elevate when it needs to automatically so people can just use the default install and go about their business.

[sharpninja]

One final thing:

most things you do on Windows require administrative rights

This is patently false. System admins and developers may live in an admin shell, but hardly anyone else ever does. And corporate package management systems almost always allow non-elevated users to install software from a menu without admin interaction.

[ferventcoder]

most things you do on Windows require administrative rights

This is patently false. System admins and developers may live in an admin shell, but hardly anyone else ever does.

Apologies for the distinction here - we are talking related to software management. And that is still true.

And corporate package management systems almost always allow non-elevated users to install software from a menu without admin interaction.

This doesn't make the statement less true, it just means there are systems in place that work around it. As such we have an offering like this with Chocolatey for Business called Self-Service (used seamlessly with command line choco and Chocolatey GUI).

[ferventcoder]

Simply have choco elevate when it needs to automatically so people can just use the default install and go about their business.

We talked about gsudo earlier in here, which I think would be something good to look into.

[ferventcoder]

If you're new to choco, especially if you've used package managers on other platforms, the first 10 times you have to spawn a new admin PS session to run choco successfully, followed by figuring out your new app isn't on the path of the original session, and that you then need to close and re-open your original session to get the new app to work, will undoubtedly lead to a mild level of rage (as it still does for me, many years and installs later).

On this aspect, other platforms have a sudo which means you don't have to open a new session. It's annoying that Windows doesn't have this. However gsudo does do this. So maybe it would be a good workaround until we could have something in place that would support how you work.

Defaulting to installing to $env:userprofile/.choco or something can still trigger UAC as necessary but avoid it altogether for portable apps.

Right now there isn't a concept of user-based installations in Chocolatey, it's all system-based. It's a MUCH bigger concept that we want to explore at some point and it comes with all kinds of interesting edge cases. It's not something we'd be able to implement overnight.

As for scripts in packages, the user's script policy should be responsible for that.

We'll disagree on this point. It has very little to do with policy, it's more ensuring that you are running what has been validated and not having something inject a change prior to that. Security is paramount.

[ferventcoder]

then close my original powershell window and reopen it so the new app shows up on the path.

Why would you do this? Do you know about refreshenv?

[ferventcoder]

https://chocolatey.org/docs/troubleshooting#i-cant-get-the-powershell-tab-completion-working

There is a small documentation bug with the next item where the profile installation is:

# Chocolatey profile
$ChocolateyProfile = "$env:ChocolateyInstall\helpers\chocolateyProfile.psm1"
if (Test-Path($ChocolateyProfile)) {
  Import-Module "$ChocolateyProfile"
}

That goes in the file that is at $profile

We probably need to put that somewhere else - if you have a PowerShell profile that is not signed, it will add to that during install.

[sharpninja]

I have never seen that snippet get added to one of my profile scripts, on any machine, ever. And what about when a new PowerShell version is installed? This is very fragile.

[ferventcoder]

I have never seen that snippet get added to one of my profile scripts, on any machine, ever. And what about when a new PowerShell version is installed? This is very fragile.

Zero changes since we put it in, and when you upgrade PowerShell it just works - for like 5+ years. But sure...I guess you can say that's fragile.

[vexx32]

It has a built in prerequisite that you must already have a profile script present for it to add anything to.

It doesn't create it automatically (IMO it should, but that's a bit of a different issue 😉). That prereq alone is usually why I'm missing said tab completions.

Anyway, we're getting a bit off topic here 😁

[ferventcoder]

IMO it should, but that's a bit of a different issue

It used to. However that had its own set of issues related to VMs, Vagrant, and Virtualbox.

[vexx32]

Ah, yeah? Not familiar enough with the issues that'd cause, but that at least explains it. I just have to get better at remembering to add it to my profile later. 😁

[ferventcoder]

#834 is where the issue is documented, #833 is where we did the work for exclusion rules.

[tapika]

Wrote initial prototype on automatic process elevation.
See #2130