Azure-pipelines-tasks: Feature request: run PowerShell as sudo

[TylerLeonhardt]

Troubleshooting

Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting

Environment

• Server - Azure Pipelines or TFS on-premises?

  • If using Azure Pipelines, provide the account name, team project name, build definition name/build number:

account name: mtntop
team project name: PowerShell-IoT-Projects
build definition: PowerShell-IoT-Projects-CI (1)
build number: 20

• Agent - Hosted or Private:
  
  
  
  • If using private agent, provide the OS of the machine running the agent and the agent version:
  
  

OS: Raspbian Linux ARM
Agent version: v2.141.0

Issue Description

This is really a feature request... Basically, I have a command in PowerShell that requires pwsh to have been run with sudo.

What I would like is some way to tell the agent to run pwsh with sudo so that this command doesn't fail.

Any way to do this today? I could only find #5073 but it seems to have been abandoned.

[bergmeister]

Since this is a private agent, I assume you know the sudo password, therefore as a temporary workaround you could use this trick from my blog post here:
``powershell echo ReplaceMeWithSudoPassword | sudo -S command ```` This tricks works in any shell btw, therefore you could run e.g.pwsh -commandorpws -filefrom an unelevatedpwsh` session

[TylerLeonhardt]

Oh for sure! I'm doing something similar already.

I'd still love to be able to set:

sudo: true

In the yaml to have the task run as sudo or admin.

[bergmeister]

Sure, the file where you would need to make that change is here (Linux/Mac is using this ts file, Windows is using the other ps1 file, therefore you'd only need to change that ts file). For adding the additional sudo parameter, see my PR here as an example to how to modify the JSON task files

[ericsciple]

@vtbassmatt owns this so he should weigh in first

[bryanmacfarlane]

I don't think we should add a sudo param - it's OS specific. Why can't you just do "the workaround". At least that's well documented and clear what it will do when you look at it.

[TylerLeonhardt]

Then I'm not really enjoying the luxury of the PowerShell task at that point, right?

I could use regular "command" task (forgot what it's called exactly) at that point to invoke the sudo'd PowerShell.

I'd personally be fine with a mechanism for running all the agent's tasks sudo'd.

This workaround, IMO, isn't ideal. Especially since you can run into silly things like #1863

[vtbassmatt]

If there's a cross-plat way to tell both implementations of PowerShell that they should run elevated, I'd consider adding that to the task (and the YAML syntax). But I'm with Bryan, sudo is a platform-ism that I don't want to add to the syntax.

Since you control the agent, can you give its identity password-less sudo? Then you don't have to play games with passing secrets around. You get the benefits of the PowerShell task, you just happen to be running a command that starts with "sudo".

[TylerLeonhardt]

I want to revisit the sudo: true but perhaps there's a different way to look this, temporarily.

On Linux the agent runs using systemd right? We should be able to specify the user to run as root in its configuration, no?

Then child processes will be root already.

I do have a concern with the fact that everything will be running as root... But that's what I need for my use case.

That just makes this a change in the start up script to allow passing in a user to run as (if this isn't already a thing).

Am I correct with this understanding?

RE: cross-platform: I don't think this is a concern because Windows doesn't really have a command-level sudo. You're either elevated or not at the process level.

[vtbassmatt]

With private agents, you decide how to run the agent. We offer a script to help you get running under systemd but we don't assume you are. It sounds like that configuration is right for you, since you know the risks about running as root.

[deadlydog]

This missing feature is a major pain. For others who need a work around until the feature gets added, you can do an inline script and use Invoke-Command. Here's an example of what we're doing in our organization (you may not need/want the CredSSP authentication), and may need to modify it to pass script parameters as well.

# The script needs to run as admin, so we can can't use the out-of-the-box "PowerShell on target machines" task :(. So use an inline script instead.
[string] $serverNames = '$(RemoteServers)' # A comma separated list of servers.
[string] $scriptPath= '$(ScriptFilePathOnRemoteServers)'
[string] $username = '$(DeployUsername)'
[SecureString] $password = '$(DeployPassword)' | ConvertTo-SecureString -AsPlainText -Force
Write-Host "Connecting to remote servers to run the script."

[string[]] $servers = $serverNames -split ','
$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username,$password

$runScriptScriptBlock = {
    param([string] $scriptPath)
    & $scriptPath
}

Invoke-Command -ComputerName $servers -Credential $credential -Authentication Credssp -ScriptBlock $runScriptScriptBlock -ArgumentList $scriptPath

[damccorm]

I don't think we want to do this for the reasons Matt and Bryan listed above - there's just not a great cross-plat way of doing this - so I'm going to close.

@deadlydog I think you're talking about a different task entirely (PowerShell vs PowerShell on target machines)