Running as app user causes permission error loading /etc/container_environment

[bethesque]

Thank you everyone for your work on the passenger docker image for Ruby apps.

We are having problems running the docker image as the app user as per the instructions here: https://github.com/phusion/passenger-docker#the-app-user

Steps to replicate:

git clone https://github.com/bethesque/passenger-run-as-app
cd passenger-run-as-app
docker-compose up

Expected behaviour:

The docker container should start up and run the_app on port 80.

Actual behaviour:

The container does not start up and the following error is shown:

Attaching to passenger-run-as-app_the_app_1
the_app_1  | *** Killing all processes...
the_app_1  | Traceback (most recent call last):
the_app_1  |   File "/sbin/my_init", line 414, in <module>
the_app_1  |     main(args)
the_app_1  |   File "/sbin/my_init", line 330, in main
the_app_1  |     import_envvars(False, False)
the_app_1  |   File "/sbin/my_init", line 90, in import_envvars
the_app_1  |     for envfile in listdir("/etc/container_environment"):
the_app_1  |   File "/sbin/my_init", line 74, in listdir
the_app_1  |     return sorted(os.listdir(path))
the_app_1  | PermissionError: [Errno 13] Permission denied: '/etc/container_environment'

The container starts correctly if the USER app line is removed. Unfortunately, there are some organizations where the security policy does not allow docker images to run as root, so we are very interested in finding a solution to this. I have some vague memory of seeing an issue indicating that the issue was with passenger itself, and needing root permissions to manage certain processes, but I cannot find it now.

Related issue: DiUS/pact_broker-docker#81

[bethesque]

Ah! I think the reason it needs to run as root may be nginx. https://stackoverflow.com/questions/42329261/running-nginx-as-non-root-user Or rather, the fact that it needs to start on port 80.

Because: Only root processes can listen to ports below 1024. A webserver typically runs at port 80 and/or 443. That means it needs to be started as root.

[CamJN]

Can you try changing the permissions on /etc/container_environment in your Dockerfile such that the app user can read that file?

[CamJN]

The port thing can be handled by changing the nginx config to listen on another port, and then setting a port redirection in docker itself.

[bethesque]

Unfortunately this doesn't work for the Ruby application because of this annoying line in the Rack URLMap code: https://github.com/rack/rack/blob/master/lib/rack/urlmap.rb#L57

Because simply mapping the port from the outside world to the inside world doesn't actually rewrite the request, the rack code thinks that the port doesn't match because the port it's addressed to doesn't match the port it's come in on (as far as I can remember from my last investigation when I attempted to do this myself).

[bethesque]

Having said that, I've failed to reproduce the issue in my demo app bethesque/passenger-run-as-app@9448ca0 , so I'll see if I can reproduce it in the full application

[YOU54F]

Looking into the issue, as to why we can't run as a non-root user. It appears to be with phusion-baseimage that passenger-docker is built upon, and the /sbin/my_init script that is called.

phusion/baseimage-docker#264 (comment)

The mention two things to get this to work

CMD ["/sbin/my_init","--","setuser","app","bash"]

Change perms on /etc/container_environment
https://github.com/phusion/baseimage-docker#security

# Make these world readable https://github.com/phusion/baseimage-docker#security
RUN chmod 755 /etc/container_environment
RUN chmod 644 /etc/container_environment.sh /etc/container_environment.json

A working example taken from @bethesque's example app, replicating the issue.
https://github.com/YOU54F/passenger-run-as-app/pull/1/files

Running as a non-root user means you lose cron / syslog / logrotate

here is another issue with running as non root on the heroku platform

phusion/baseimage-docker#475

[bethesque]

Closing issue. We ended up going with puma on an alpine ruby base image for a couple of reasons. 1. the size of the image and 2. running the application without root permissions is required for a lot of managed docker deployment tools, and this was easier with puma. The fact that the docker cluster management tools are responsible for maintaining the HA environment means that it's not as important to us to have processes inside the container to reboot processes when they go down.

Thanks again for your work on this however.