We use hardened images that have noexec set on /tmp mount, therefore we need to use another directory for plugins exec. That works fine on 0.7.5 - and so far I am locked in that version, because newer versions (apparently) ignore the setting altogether.
The configuration is the same for both test cases, such as:
With 0.7.5 the service start normally.
With 0.9.0, though, it fails, with the same configuration, due to noexec on /tmp:
Jun 27 16:07:50 ip-10-237-99-241.eu-central-1.compute.internal systemd[1]: Started Access any system from anywhere based on user identity.
Jun 27 16:07:50 ip-10-237-99-241.eu-central-1.compute.internal boundary[10347]: Error parsing KMS configuration: error fetching kms plugin rpc client: fork/exec /tmp/3286585514/boundary-plugin-kms-awskms.gz: permission denied
Jun 27 16:07:50 ip-10-237-99-241.eu-central-1.compute.internal systemd[1]: boundary.service: main process exited, code=exited, status=3/NOTIMPLEMENTED
Jun 27 16:07:50 ip-10-237-99-241.eu-central-1.compute.internal systemd[1]: Unit boundary.service entered failed state.
Jun 27 16:07:50 ip-10-237-99-241.eu-central-1.compute.internal systemd[1]: boundary.service failed.
Can anyone tell me if I’m missing something please? Has the directive changed by any chance?
Just updating this topic to let you know that we’ve been able to reproduce this internally with the kms plugin. This regression appears to have been introduced in v0.8.0. We’ll try to get a fix out as soon as possible. Thanks for reporting the issue!
The regression was introduced because when kms plugins were introduced in 0.8.0 they unfortunately weren’t set up to honor the execution dir the same way host plugins were. @johanbrandhorst has this fixed and it will go out in 0.9.1 as far as I know!