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.
@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.
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.
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"
Do you have a debug log for this one?
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
Once you've downloaded the file, you should use Install-ChocolateyInstallPackage, not Install-ChocolateyPackage
I wonder what may have changed with Windows 10 and elevation. Apparently it may not be enough to use RunAS anymore.
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?
Right now you are copying the file onto itself. Install-ChocolateyPackage is a superset of Get-ChocolateyWebFile and then Install-ChocolateyInstallPackage.
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
I can confirm that choco just fails on non-admin console on win10.
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?
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).
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 :/
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.
``` C#
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);
}
}
}
```
Actually, it appears that we do switch on UseShellExecute to true, but somehow we are still redirecting StdErr?
It's done through EnableRaisingEvents though
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
@ferventcoder why don't you use git-flow approach to resolve this issue in stable to don't keep users waiting for rewrite?
@Link-Satonaka are your Win10 instance is clean install or upgrade? I have a clean install one from 1511 ISO.
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.
@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.
Can we determine if this is now fixed with the latest beta?
https://chocolatey.org/packages/chocolatey/0.9.10-beta-20160111 (note it may not be ready for 1-3 hours while the validator and verifier run).
Sorry, still not working
https://gist.github.com/Link-Satonaka/40cd66d4e0400d939020
Thanks for checking. Dragging out the important parts here - it looks like using ProcessStartInfo.Verb = RunAs may no longer work on Windows 10.
:39:32,713 [DEBUG] - Setting RunAs for elevation
2016-01-11 15:39:32,758 [WARN ] - WARNING: Write-ChocolateyFailure is deprecated. If you are the package maintainer, please use 'throw $_.Exception' instead.
2016-01-11 15:39:32,758 [ERROR] - ERROR: Exception calling "Start" with "0" argument(s): "The requested operation requires elevation"
at Write-ChocolateyFailure, C:\tools\Chocolatey\helpers\functions\Write-ChocolateyFailure.ps1: line 24
at <ScriptBlock>, C:\tools\Chocolatey\lib\paint.net\tools\chocolateyInstall.ps1: line 12
at <ScriptBlock>, C:\tools\Chocolatey\helpers\chocolateyScriptRunner.ps1: line 48
But UseShellExecute must be true for the runas verb (for the UAC prompt) to have any effect. See https://stackoverflow.com/a/3596354.
Or as previously stated (https://github.com/chocolatey/choco/issues/434#issuecomment-158792680), using UseShellExecute must be set true.
I was under Windows 8.1 when I opened this :)
Looking at the comments for this thread http://stackoverflow.com/questions/133379/elevating-process-privilege-programatically
someone mentioned that StartInfo.UseShellExecute must be $true for RunAs to work.
Beat me to it by 36 seconds
Yeah. I think at one time this worked, then we started redirecting output and it stopped working.
up?
I am getting this with Windows 7. I have a separate user account for admin and I'm trying to run choco as regular user.
Installing jdk8...
DEBUG: Running 'Start-ChocolateyProcessAsAdmin' with
exeToRun:'C:\ProgramData\chocolatey\lib\jdk8\tools\jdk-8u92-windows-x64.exe', statements: '/s STATIC=1
ADDLOCAL="ToolsFeature,SourceFeature" '
DEBUG: Elevating Permissions and running C:\ProgramData\chocolatey\lib\jdk8\tools\jdk-8u92-windows-x64.exe /s STATIC=1
ADDLOCAL="ToolsFeature,SourceFeature" . This may take a while, depending on the statements.
Exception calling "Start" with "1" argument(s): "The requested operation requires elevation"
At C:\ProgramData\chocolatey\helpers\functions\Start-ChocolateyProcessAsAdmin.ps1:76 char:3
+ $s = [System.Diagnostics.Process]::Start($psi)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : Win32Exception
Command ['"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -NoLogo -ExecutionPolicy Bypass -Comman
d "[System.Threading.Thread]::CurrentThread.CurrentCulture = '';[System.Threading.Thread]::CurrentThread.CurrentUICultur
e = ''; & import-module -name 'C:\ProgramData\chocolatey\helpers\chocolateyInstaller.psm1'; & 'C:\ProgramData\chocolatey
\helpers\chocolateyScriptRunner.ps1' -packageScript 'C:\ProgramData\chocolatey\lib\jdk8\tools\chocolateyInstall.ps1' -in
stallArguments '' -packageParameters ''"'] exited with '1'
Calling command ['"shutdown" /a']
@lhahne the workaround right now is to run with admin privileges. We'll get that fixed in an upcoming version.
As @ferventcoder said, run chocolatey in admin elevated powershell for now. For apps that install to appdata (like chromium), I have gotten away with running powershell/chocolatey as my user to specially handle running cup chromium
pleaserino fixerino the bugerino
it's very annoying to have to run cmd/powershell in admin mode every time
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.
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
}
Most helpful comment
I can confirm that choco just fails on non-admin console on win10.