Plugin Install, tmp, and noexec

[bmlong137]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Overview of the Issue

When installing a plugin, either by using packer plugins install or packer init, the plugins are first downloaded to /tmp before being moved to the PACKER_PLUGIN_PATH directory. Before that move takes place, a describe command is executed on them. I am not sure of the purpose, but this effectively requires executable permission on the file.

When /tmp is mounted with noexec, this is not possible. So in these cases, plugin downloads are only possible by manually downloading them and using the packer plugins install --path option.

The issue is rather obvious; the question is whether it should be resolved and if so, how it should be resolved.

• Do not resolve
• Allow for custom temporary folder download for plugin installs, much like remote_path for provisioners
• Do not execute the command in the temporary location

Reproduction Steps

Mount /tmp with the noexec option and try to install any Packer plugin. It is pretty easy and consistent to reproduce.

Packer version

From v1.11.2

Operating system and Environment details

Red Hat Enterprise Linux. We are operating in an SELinux environment with several security features enabled, hence noexec on the /tmp mount.

[mogrogan]

Thank you for your report @bmlong137

I think the solution with a custom temporary folder is the right one. As it's a runtime related configuration, I would put this in an environment variable.

relabelling the issue as enhancement since packer seems to behave as intended.

[mogrogan]

hi @bmlong137

Can you try setting TMPDIR environment variable before calling the init command?