Chocolatey doesn't elevate

[AeliusSaionji]

First- I'm using the proper User / Admin configuration that the Windows userbase tend to scoff at. That is, I use a "User" account, and when I "Run as Admin" UAC runs the executable under an entirely different "Admin" account. This is par for the course in linux, but as I'm sure you're aware most Windows users tend to just create one Administrative account and call it a day.

I bring this up because there's a good chance this is the root of the issue- something is written so that it works in an Administrative account and doesn't actually properly utilize UAC. I don't really know anything about how chocolatey is set up, but I do know that the powershell
Start-Process $process -Verb Runas
correctly requests elevation for both User and Admin type accounts.

The problem: chocolatey does not elevate processes for me. Many installers internally request elevation, so the problem appears intermittent, but I'm fairly certain chocolatey consistently fails every time it tries to elevate a process itself. As such, whichever packages in the repo that rely on chocolatey to elevate WILL fail unless I run cinst from an administrative powershell terminal.

[ferventcoder]

@Link-Satonaka you've probably had a look through Start-ChocolateyProcessAsAdmin.

https://github.com/chocolatey/choco/blob/master/src/chocolatey.resources/helpers/functions/Start-ChocolateyProcessAsAdmin.ps1#L66 is the line where it passes -Verb "runas". I think something else may be going on for you somewhere here.

If you wouldn't mind, use choco install -dv plus your arguments, then send the entire log of the output along as a gist for further review.

[ferventcoder]

As such, whichever packages in the repo that rely on chocolatey to elevate WILL fail unless I run cinst from an administrative powershell terminal.

Also, if you haven't had a chance, you should read up on why you need to change the default install location - https://github.com/chocolatey/choco/wiki/Installation#non-administrative-install

Note that non-admins can write to the default install location, but they cannot append or modify existing files. We are locking this down further in 0.9.9.9, see #398.

[AeliusSaionji]

Noted, thanks.

It's strange, the paint.net installer will request elevation if run, but when passed through Start-ChocolateyProcessAsAdmin, it fails with Exception calling "Start" with "1" argument(s): "The requested operation requires elevation"

[ferventcoder]

Do you have a debug log for this one?

[AeliusSaionji]

Using this install script http://sprunge.us/MTGd

$packageName = 'paint.net'
$fileType = 'EXE'
$silentArgs = '/auto DESKTOPSHORTCUT=0'
$url = '{{DownloadUrl}}'

# Zipped installer
Get-ChocolateyWebFile $packageName "$ENV:Temp\paint.net.install.zip" $url
Get-ChocolateyUnzip "$ENV:Temp\paint.net.install.zip" "$ENV:Temp\pdn"
$installFile = Get-ChildItem -Path "$ENV:Temp\pdn" -Recurse -Include "*.exe" | Select-Object -First 1

# elevation bug
Install-ChocolateyPackage $packageName $fileType $silentArgs $installFile
#Start-Process -FilePath "$installFile" -ArgumentList "$silentArgs" -Verb Runas

Dump of the log
http://sprunge.us/eEfR

[ferventcoder]

Once you've downloaded the file, you should use Install-ChocolateyInstallPackage, not Install-ChocolateyPackage

[ferventcoder]

I wonder what may have changed with Windows 10 and elevation. Apparently it may not be enough to use RunAS anymore.

[AeliusSaionji]

Did not know about Install-ChocolateyInstallPackage, but the results do not change. What is the difference, it just doesn't copy the binary to TEMP?

http://sprunge.us/dgXS

[ferventcoder]

Right now you are copying the file onto itself. Install-ChocolateyPackage is a superset of Get-ChocolateyWebFile and then Install-ChocolateyInstallPackage.

[AeliusSaionji]

OK, yeah I noticed it copied the file when using Install-ChocolateyPackage and I intentionally extracted it to TEMP\pdn so it would not throw "file exists" errors. Good to know there's a better way, thanks

[yurikoles]

I can confirm that choco just fails on non-admin console on win10.

[iainnicol]

The problem is that Start-ChocolateyProcessAsAdmin sets UseShellExecute to false. This is required to redirect stderr. But UseShellExecute must be true for the runas verb (for the UAC prompt) to have any effect. See https://stackoverflow.com/a/3596354.

I've seen named pipes mooted as a hairy workaround. But I have a slightly less hairy workaround. First use Start-Process -Verb runas to execute a private, intermediary, script as admin. The intermediary script then does Start-Process -RedirectStandardError and executes the process we're actually trying to execute.

Would it be ok to stick such a private, intermediary, script in the same src/chocolatey.resources/helpers/functions/ directory as Start-ChocolateyProcessAsAdmin.ps1?

[ferventcoder]

Would it be ok to stick such a private, intermediary, script in the same src/chocolatey.resources/helpers/functions/ directory as Start-ChocolateyProcessAsAdmin.ps1?

Probably not. We are working on rewriting these functions into c# cmdlets. We won't have the same issues when we do that (I know this for a fact as that is what shimgen does already).

[AeliusSaionji]

Using Win10, no new issues for me since 8.1 with chocolatey, @yurikoles
In other news, I tried correctly installing chocolatey to a folder outside of programdata and due to this bug almost no packages are install-able :/

[iainnicol]

Probably not. We are working on rewriting these functions into c# cmdlets.

Understandable.

We won't have the same issues when we do that (I know this for a fact as that is what shimgen does already).

OK, I'm still pretty sure about my diagnosis. I presume shimgen isn't redirecting stderr?

Here's a minimal testcase. It doesn't invoke UAC, because UseShellExecute = false to allow RedirectStandardError = true.

using System.Diagnostics;

namespace StartProcessTest
{
    class Program
    {
        static void Main(string[] args)
        {
            var procInfo = new ProcessStartInfo("notepad");
            procInfo.RedirectStandardError = true;
            procInfo.UseShellExecute = false;

            procInfo.Verb = "runas";

            Process.Start(procInfo);
        }
    }
}

[ferventcoder]

Actually, it appears that we do switch on UseShellExecute to true, but somehow we are still redirecting StdErr?

[ferventcoder]

It's done through EnableRaisingEvents though

[iainnicol]

Interesting. Honestly, I'm a bit confused. Regardless, I'll leave this for now given the planned rewrite.

@Link-Satonaka, for an ugly interim workaround, I suggest you comment out the following lines of chocolatey\helpers\functions\Start-ChocolateyProcessAsAdmin.ps1:

$psi.RedirectStandardError = $true # L59
$psi.UseShellExecute = $false # L60
$s.StandardError.ReadToEnd() | Out-File $errorFile # L81
$innerError = Get-Content $errorFile | Out-String # L88

[yurikoles]

@ferventcoder why don't you use git-flow approach to resolve this issue in stable to don't keep users waiting for rewrite?

[yurikoles]

@Link-Satonaka are your Win10 instance is clean install or upgrade? I have a clean install one from 1511 ISO.

[ferventcoder]

why don't you use git-flow approach to resolve this issue in stable to don't keep users waiting for rewrite?

@yurikoles I'm not quite sure what you are referring to. If you are talking about a quick fix and then a permanent fix later, that really doesn't have anything to do with git-flow. And really neither does stable vs master. Git Flow is an approach to development but it doesn't dictate where one should resolve an issue. Most common workflows would do a bug fix in the stable branch.

[ferventcoder]

@yurikoles rewrite - Now I understand. We already pushed master to stable in preparation for 0.9.10. If we think this is a big enough issue, I can create a 0.9.9.x branch off of the last tag and move forward there. However I am working on a possible fix right now.

[Baemir]

pleaserino fixerino the bugerino

it's very annoying to have to run cmd/powershell in admin mode every time

[ThaJay]

This is a dealbreaker for me.

I would expect (being a long time Windows user) to just be able to run a choco install command and not have to worry about it. When elevation is needed, Windows will prompt me. Instead I get this wall of text saying I need to run my terminal as admin.

I am very happy to use Windows Terminal nowadays and it has really improved my workflow by a lot. I have all my git bash, wsl and powershell windows neatly in tabs inside one window. It would thus really hurt my workflow to open a new cmd window as admin just to execute choco commands and I'd rather just execute a downloaded installer because of this.

please fix. If you do, that's one step closer to unix for developers and one argument less to ditch Windows for Ubuntu or something.

[AeliusSaionji]

Here's a few very basic functions you can add to your powershell profile to maintain a good workflow.

Function cupall {
	$env:LOCALAPPDATA = "C:\Users\$env:USERNAME\AppData\Local"
	$env:USERPROFILE = "C:\Users\$env:USERNAME"
	Start-Process -FilePath 'powershell.exe' -ArgumentList 'cup all -y; Read-Host' -Verb RunAs
}

Function cinst {
	param (
		[Parameter(Mandatory = $true)]
		[string]$package
	)
	$env:LOCALAPPDATA = "C:\Users\$env:USERNAME\AppData\Local"
	$env:USERPROFILE = "C:\Users\$env:USERNAME"
	Start-Process -FilePath 'powershell.exe' -ArgumentList "cinst $package; Read-Host" -Verb RunAs
}

Function cuninst {
	param (
		[Parameter(Mandatory = $true)]
		[string]$package
	)
	$env:LOCALAPPDATA = "C:\Users\$env:USERNAME\AppData\Local"
	$env:USERPROFILE = "C:\Users\$env:USERNAME"
	Start-Process -FilePath 'powershell.exe' -ArgumentList "cuninst $package; Read-Host" -Verb RunAs
}

[technic]

Hey. Is there any updates on this issue?

[pauby]

@technic This is on the backlog but isn't something we have prioritized just now.

[saxophone-dev]

Any updates?
It's been around an year.

[pauby]

If we are working on an issue we will update the labels, add comments etc. You'd see some activity here.

We're not working on this at the moment. To set expectations, we don't have any plans in the immediate future. It is something we do want to look at and implement, if possible, but have no timescales to share.

[vexx32]

Testing this with a simple test-case package which just calls Install-ChocolateyPath -PathToInstall $path -PathType Machine (which requires elevation) in Chocolatey v2.2.2, at least in a Vagrant VM environment (which may impact how UAC is configured, I'm not fully sure), this kind of operation where you try to do something that requires elevation as a non-admin user... seems to recursively spawn new PowerShell processes "trying" to elevate the process, but never actually managing to elevate the process properly.

This continues until the machine runs out of memory and Windows seems to sometimes prompt to kill the misbehaving process tree.

As is noted in our documentation, the non-admin installation configuration is... not straightforward and we don't expect this kind of thing to work in a lot of cases.

There may be something to be said for the Start-ChocolateyProcessAsAdmin command we have being simply not functional for what it's meant to do (anymore?) and we may want to consider reworking some of these code paths to simply throw an error rather than attempt to start an elevated PowerShell process, which we know doesn't actually work.

[schittli]

This is an unbelievable shame ...

and perhaps it will help the project to understand why potential customers quickly remove Chocolatey from the evaluation:

1. We have 750 employees and wanted to use Chocolatey for deploy - and this 9 year old shame (Issue) is one of the reasons why we didn't choose Choco: the handling is just a nightmare.
2. In 99/100 installations by our employees, we just want to be able to tell them: Run the command “choco install <packagename>” - and everything else runs automatically.
3. But with Chocolatey, the user receives an incomprehensible message that they have to start the elevated session manually.
4. Of course, we do not want to create a manual or YouTube video, how our employees can use Choco
5. Of course, we also don't want to customize the choco.exe.manifest - this “concept” is once again a nightmare because we don't want to maintain this file

So one of the most important key features for a tool like Chocolatey is:

1. that end users can install SW very easily
2. and that the tool itself requests the elevated permissions
3. if the package specifies this

So we are curious to see whether Choco will manage to provide this trivial basic function in the next decade - I hope it very much, because Chocolatey has som really great features 😃

[pauby]

and perhaps it will help the project to understand why potential customers quickly remove Chocolatey from the evaluation:

With Chocolatey for Business Self Service, elevation happens in the background, so the user isn't prompted to do anything. This is not a feature of Chocolatey FOSS.

Are you using Chocolatey for Business?