Erroneous escape sequence of environment variables in powershell provisioner

[Occams]

After upgrading to packer 1.1.1 we experience an error during one particular powershell provisioning step.

By examining the packer logfile it seems clear that there was a change in how powershell environment variables specified in the script are handled.

Powershell provisioner snippet:

{ "type": "powershell", "script": "scripts/preinstalled/apply-settings.ps1", "remote_path": "C:/Windows/Temp/scripts/apply-settings.ps1", "environment_vars": [ "path_target={{ user ``path_target`` }}" ], "valid_exit_codes": [ 0 ] }

The user variable path_target evaluates to a path including a terminating backslash: C:\Foobar\

Snippets from the logfile:

• Packer 1.1.0 2017/10/17 12:09:18 packer.exe: 2017/10/17 12:09:18 Building command line for: if (Test-Path variable:global:ProgressPreference){$ProgressPreference='SilentlyContinue'};$env:PACKER_BUILDER_TYPE="virtualbox-ovf"; $env:PACKER_BUILD_NAME="vbox-preinstalled-win10"; $env:path_target="C:\Foobar\"; &'C:/Windows/Temp/scripts/apply-settings.ps1';exit $LastExitCode
• Packer 1.1.1 2017/10/17 09:57:48 packer.exe: 2017/10/17 09:57:48 [INFO] command 'powershell -executionpolicy bypass "& { if (Test-Path variable:global:ProgressPreference){$ProgressPreference='SilentlyContinue'};$env:PACKER_BUILDER_TYPE=\"virtualbox-ovf\"; $env:PACKER_BUILD_NAME=\"vbox-preinstalled-win10\"; $env:path_target=\"C:\Foobar\\"; &'C:/Windows/Temp/scripts/apply-settings.ps1';exit $LastExitCode }"' exited with code: 1 2017/10/17 09:57:48 packer.exe: 2017/10/17 09:57:48 [INFO] RPC endpoint: Communicator ended with: 1 2017/10/17 09:57:48 [INFO] 0 bytes written for 'stdout' 2017/10/17 09:57:48 [INFO] 201 bytes written for 'stderr' 2017/10/17 09:57:48 [INFO] RPC client: Communicator ended with: 1 2017/10/17 09:57:48 [INFO] RPC endpoint: Communicator ended with: 1 2017/10/17 09:57:48 ui: vbox-preinstalled-win10: Die Zeichenfolge hat kein Abschlusszeichen: ". 2017/10/17 09:57:48 ui: vbox-preinstalled-win10: + CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException 2017/10/17 09:57:48 ui: vbox-preinstalled-win10: + FullyQualifiedErrorId : TerminatorExpectedAtEndOfString

The issue seems to be an erroneous escape sequence: $env:path_target=\"C:\Foobar\\"; Dynamic input should be suspect to escaping if required.

Complete packer logfile: https://gist.github.com/Occams/963ba4808f5045f9ad0b73862bb06ddb

[SwampDragons]

Thanks for reporting this and apologies for the regression. I'll take a look as soon as I can.

[SwampDragons]

Okay this is because we changed the env var format:

-               p.config.EnvVarFormat = `$env:%s="%s"; `
+               p.config.EnvVarFormat = `$env:%s=\"%s\"; `

The final result seems to be that we've managed to escape the backslash that was supposed to escape the quote, instead of escaping the quote.

you can work around it by adding an extra escaped slash to your config; e.g.

      "environment_vars": [
        "path_target=C:\\Foobar\\\\"
      ]

I'll see if I can add some better brains to the script to make it look for a trailing slash, but we're unlikely to get to that before https://github.com/hashicorp/packer/pull/5376, since I don't want to change the escape behavior every release.

Sorry for changing this on you.

[SwampDragons]

Actually, since you are requesting dynamic escaping and that's what #5376 is meant to do, I'm going to close this as a duplicate and make sure that we use this ticket as a test case when merging the other ticket. Thanks for reporting!

[SwampDragons]

😅 nevermind, that's a PR and not an issue. I'll just reference this issue in that PR.

[DanHam]

@SwampDragons Seeing as I broke this (sorry @Occams!) I have taken an in depth look and submitted #5515 to fix.

Note that this particular problem wouldn't actually be fixed by #5376... or at least shouldn't really be fixed by #5376 as a backslash isn't interpreted or considered special by PowerShell.

The root cause of the issue is the fact that the non-privileged PowerShell provisioner embeds the env vars directly in the command string. This means that we need to escape all the characters in the env vars that would otherwise cause the command string to be interpreted incorrectly. Clearly, this is quite a troublesome task...

A much better approach is to fix the problem by following (ripping off!) the changes you made to the elevated PS command in #5435 - namely uploading and dot sourcing the env vars rather than embedding them in the command string directly. Clearly this will fix a lot of the problems we have been seeing previously...

Note that currently the elevated PS provisioner can handle the trailing slash on that env var without issue. The changes made in the PR allow the non-privileged PS provisioner to do the same.

Note that regardless of the changes in that PR, characters special to PowerShell in user env vars ( and passwords etc) will still need escaping so that they are correctly interpreted by PowerShell - see the sample template in the PR for examples. Hopefully #5376 will eventually automate that for us...

@Occams Again, apologies breaking things! Note that if the new PR gets accepted and merged, the behaviour should revert back to what it was in the previous version...

[Occams]

@DanHam That's the solution I was hoping for :-)

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.