You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
resource"local_file""some_file" {
content="Can be anything"filename="${var.output_path}/some_file.txt"
}
// var.output_path is interpolated in based on where the directory is located// which is typically in a Git repo dir under a home username
Expected Behavior
# local_file.some_file will be created+resource"local_file""some_file" {
+content="Can be anything"+directory_permission="0777"+file_permission="0777"+filename="/home/my_user/some_repo/outputs/some_file.txt"+id=(known after apply)
}
Actual Behavior
terraform plan gives:
Error: open /home/some_user/some_repo/outputs/some_file.txt: permission denied
Steps to Reproduce
Use the resource local_file to write into some directory. Change either the directory or file permissions such that your username can no longer read the file.
Now use back the same local_file resource, but change the filename value and write into another directory and try to do terraform plan. Even though the user has permission to write into this new directory, but because the provider tries to read the old path and fails due to missing read permission, the local_file read operation fails.
Note
While this is not a bug, in a scenario where multiple usernames need to use a shared instance to run Terraform operations with local_file resource, this will typically result in the above described permission denied situation, and can be annoying to mitigate.
One possible mitigation is to have every username open up their output directories to allow read permissions for every other usernames. However this is not ideal as it results in a weaker security posture.
On the other hand, if we could allow the provider to treat failed reading of content due to read permission issue, similarly to missing file (which is already present in the code), the whole issue can be avoided. It also resolves some edge cases; if the username chooses to create local_file without file read / dir execution permissions, every subsequent terraform plan would fail, since the previously created file cannot be read back, despite in the same filename location (admittedly, this is a far-fetched case).
Terraform Version
Terraform v0.12.29
Affected Resource(s)
local_file
Terraform Configuration Files
Expected Behavior
Actual Behavior
terraform plan
gives:Steps to Reproduce
Use the resource
local_file
to write into some directory. Change either the directory or file permissions such that your username can no longer read the file.Now use back the same
local_file
resource, but change thefilename
value and write into another directory and try to doterraform plan
. Even though the user has permission to write into this new directory, but because the provider tries to read the old path and fails due to missing read permission, thelocal_file
read operation fails.Note
While this is not a bug, in a scenario where multiple usernames need to use a shared instance to run Terraform operations with
local_file
resource, this will typically result in the above described permission denied situation, and can be annoying to mitigate.One possible mitigation is to have every username open up their output directories to allow read permissions for every other usernames. However this is not ideal as it results in a weaker security posture.
On the other hand, if we could allow the provider to treat failed reading of content due to read permission issue, similarly to missing file (which is already present in the code), the whole issue can be avoided. It also resolves some edge cases; if the username chooses to create
local_file
without file read / dir execution permissions, every subsequentterraform plan
would fail, since the previously created file cannot be read back, despite in the samefilename
location (admittedly, this is a far-fetched case).References
PR: #56
The text was updated successfully, but these errors were encountered: