Scripts placed in /docker-entrypoint.d/ cannot perform useful work because root user access is unavailable

[RulerOf]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• 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.

---

• I'd be willing to implement this feature (contributing guide)

Describe the user story

As an Atlantis user, I'd like for my terraform plan/apply cycles to be able to execute Python code or possibly other arbitrary command-line utilities that I could add to the container at startup through a script placed in the /docker-entrypoint.d directory.

In order to install software into the container, the script needs to run as root. All scripts currrently executed by the docker-entrypoint.sh script are run as the atlantis user.

Describe the solution you'd like

Scripts inside of the /docker-entrypoint.d directory should be run as root, or be able to run as root.

Describe the drawbacks of your solution

Most projects appear to implement this functionality with gosu in their entrypoint. gosu exposes a privilege escalation vulnerability in some scenarios when it's used from an interactive shell. According to the discussion:

The catch is that the exploit provided there only works if gosu is run from an interactive shell -- if folks are using gosu in the way that it is intended (exec gosu some-user ... at the end of a docker-entrypoint.sh script), then the parent shell is replaced by gosu, and so there is no longer an interactive shell for the exploiting command to interact with indirectly. 👍

This indicates to me that the previous approach that removed this functionality was actually safe.

Describe alternatives you've considered

• Implement a more-complex container init (such as s6-overlay) to control the user directly with PID1.

[taylor-fis]

We could get around this issue by allowing sourcing of script files, similar to how it's done in the NGINX image https://github.com/nginxinc/docker-nginx/blob/9abe4ae472b3332665fad9b12ee146dc242e775c/entrypoint/docker-entrypoint.sh#L19

That way, we could export our own PATH that includes non-root directories (EG ~/bin) and install any binaries we require there instead.

Thoughts?

(PS I'm having the exact same issue as you trying to install terragrunt at runtime, so we don't need to maintain our own docker image).

[RulerOf]

@taylor-fis I submitted a PR to reimplement root for the entrypoint. We'll see what happens ¯\_(ツ)_/¯

[chenrui333]

not a good idea.

[chenrui333]

@taylor-fis as maintainer group, we actually try to slim down the docker image support :(