Regression in 1.1: script_path in remote-exec no longer uploads file to ~ paths
#30243
Comments
|
Relevant debug output using terraform 1.1.2: |
|
And here's the same section of debug output using terraform 1.0.11: |
|
I also checked the trace logs using terraform 1.1.2 to see if there were any more details about the file upload and why/how it failed, but there was no trace output around the file upload. |
|
For comparison to a success case with terraform 1.1.2, I modified the connection to specify the full path and grabbed the same section of debug output: connection {
script_path = "/home/ubuntu/foo.sh"
} |
|
Comparing the two terraform 1.1.2 runs, the key difference appears to be that the command is now being escaped incorrectly? Success using full path: Failure using vs success using |
lorengordon
changed the title
script_path in remote-exec no longer expands ~ pathsscript_path in remote-exec no longer uploads file to ~ paths
|
Hi @lorengordon, Thanks for reporting the issue! I am fairly certain it was a security patch which changed this behavior from #28626. The provisioner's use of the remote |
jbardin
added
confirmed
|
Fwiw, our use case around |
* Terraform v1.1 changed the behavior of provisioners and `remote-exec` in a way that breaks support for expansions in commands (including file provisioner, where `destination` is part of an `scp` command) * Terraform will likely revert the change eventually, but I suspect it will take a while * Instead, we can stop relying on Terraform's expansion behavior. `/home/core` is a suitable choice for `$HOME` on both Flatcar Linux and Fedora CoreOS (harldink `/var/home/core`) Rel: hashicorp/terraform#30243
* Terraform v1.1 changed the behavior of provisioners and `remote-exec` in a way that breaks support for expansions in commands (including file provisioner, where `destination` is part of an `scp` command) * Terraform will likely revert the change eventually, but I suspect it will take a while * Instead, we can stop relying on Terraform's expansion behavior. `/home/core` is a suitable choice for `$HOME` on both Flatcar Linux and Fedora CoreOS (harldink `/var/home/core`) Rel: hashicorp/terraform#30243
* Terraform v1.1 changed the behavior of provisioners and `remote-exec` in a way that breaks support for expansions in commands (including file provisioner, where `destination` is part of an `scp` command) * Terraform will likely revert the change eventually, but I suspect it will take a while * Instead, we can stop relying on Terraform's expansion behavior. `/home/core` is a suitable choice for `$HOME` on both Flatcar Linux and Fedora CoreOS (harldink `/var/home/core`) Rel: hashicorp/terraform#30243
* Terraform v1.1 changed the behavior of provisioners and `remote-exec` in a way that breaks support for expansions in commands (including file provisioner, where `destination` is part of an `scp` command) * Terraform will likely revert the change eventually, but I suspect it will take a while * Instead, we can stop relying on Terraform's expansion behavior. `/home/core` is a suitable choice for `$HOME` on both Flatcar Linux and Fedora CoreOS (harldink `/var/home/core`) Rel: hashicorp/terraform#30243
* Terraform v1.1 changed the behavior of provisioners and `remote-exec` in a way that breaks support for expansions in commands (including file provisioner, where `destination` is part of an `scp` command) * Terraform will likely revert the change eventually, but I suspect it will take a while * Instead, we can stop relying on Terraform's expansion behavior. `/home/core` is a suitable choice for `$HOME` on both Flatcar Linux and Fedora CoreOS (harldink `/var/home/core`) Rel: hashicorp/terraform#30243
* Terraform v1.1 changed the behavior of provisioners and `remote-exec` in a way that breaks support for expansions in commands (including file provisioner, where `destination` is part of an `scp` command) * Terraform will likely revert the change eventually, but I suspect it will take a while * Instead, we can stop relying on Terraform's expansion behavior. `/home/core` is a suitable choice for `$HOME` on both Flatcar Linux and Fedora CoreOS (harldink `/var/home/core`) Rel: hashicorp/terraform#30243
* Terraform v1.1 changed the behavior of provisioners and `remote-exec` in a way that breaks support for expansions in commands (including file provisioner, where `destination` is part of an `scp` command) * Terraform will likely revert the change eventually, but I suspect it will take a while * Instead, we can stop relying on Terraform's expansion behavior. `/home/core` is a suitable choice for `$HOME` on both Flatcar Linux and Fedora CoreOS (harldink `/var/home/core`) Rel: hashicorp/terraform#30243
* Terraform v1.1 changed the behavior of provisioners and `remote-exec` in a way that breaks support for expansions in commands (including file provisioner, where `destination` is part of an `scp` command) * Terraform will likely revert the change eventually, but I suspect it will take a while * Instead, we can stop relying on Terraform's expansion behavior. `/home/core` is a suitable choice for `$HOME` on both Flatcar Linux and Fedora CoreOS (harldink `/var/home/core`) Rel: hashicorp/terraform#30243
|
Hi all! Sorry for the quiet period here while we were out for holidays. The change here was an intentional one with a security-related motivation, as discussed over in #28626. However, it does look like we missed including this in the "upgrade notes" section of the changelog and in the Terraform v1.1 Upgrade Guide, and we're sorry for not being more explicit about this change. Security-related changes are one of the pragmatic exceptions we allow in our v1.0 Compatibility Promises, with this change being made in response to explicit security feedback sent through our security reporting channels. Because of that, our internal discussion here has focused on finding a compromise to still meet this issue's stated use-case, which we understand as a need to upload into the home directory of the target user without necessarily knowing the absolute path of that home directory. Under the default configuration of sshd and scp, a relative destination path will be interpreted as relative to the target user's home directory without the need for any special metacharacters or environment variable substitutions, and Terraform's internal use of provisioner "remote-exec" {
inline = [
"echo foo"
]
connection {
script_path = "foo.sh"
}
}This issue was originally discussing the effect of Terraform's implementation detail of executing scripts by first uploading them into the remote filesystem using provisioner "file" {
content = "example"
destination = "example.txt"
}In both of these cases the relative path will be passed verbatim to the remote In order to resolve this issue, we're intending to:
We'll work on the steps I described above shortly, and close this issue once we've completed that work. Thanks again for reporting this! |
TIL. That's an interesting detail I was not aware of. Thanks for the workaround! |
|
@apparentlymart I tested but looking to confirm, the resource "null_resource" "file_copy" {
connection {
type = "ssh"
host = "x.x.x.x"
user = "root"
private_key = file("~/.ssh/id_rsa")
}
provisioner "file" {
source = "main.tf"
destination = ".test/blah.txt"
}
provisioner "remote-exec" {
inline = [
"chmod 400 ~/.test/blah.txt",
"echo 'hi' > ~/.test/blah2.txt",
"chmod 600 ~/.test/blah2.txt",
]
}
} |
|
Hi @dprosper, Indeed, the two other examples you showed here have some different handling and thus different effective behavior:
This change only applies to situations where Terraform is internally using Secure Copy Protocol, and specifically to the path arguments passed to the remote The security concern reported here is that allowing arbitrary command execution during file upload is an unexpected/unintended avenue for code execution that module authors may reasonably not consider when attempting to "harden" a Terraform module against unintended handling of externally-provided data. |
|
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. |
Terraform Version
Terraform Configuration Files
Expected Behavior
Expected terraform to create the instance, connect to it, and run the inline script. This worked fine in Terraform 1.0, but it fails in Terraform 1.1.
Actual Behavior
Provisioner fails to create the inline script in the specified location.
chmodexecutes and resolves the~, but then cannot find the file, and the provisioner exits with that error.Steps to Reproduce
terraform initterraform applyThe text was updated successfully, but these errors were encountered: