Run php:fpm as non-root

[md5]

Unlike the php:apache image where Apache drops root privileges to www-data before running any PHP code, the php:fpm image is still running as root.

Since it doesn't actually need root privileges, it would probably be best if php:fpm ran PHP code as a non-root user. In the case of php:fpm, it seems like it should work fine to use a USER fpm without pulling in gosu or anything like that.

[md5]

To accomodate switching between php:apache-based images and php:fpm-based images, it may be best to run php-fpm as www-data with the same uid as the php:apache image.

Then again, it would also be nice to be able to easily switch php:apache-based images to a user other than www-data I know I did some testing with switching the user that apache2 uses by having it pick up the APACHE_RUN_USER environment variable, but I can't for the life of me find the branch or gist (maybe it was just a comment).

In the case of php:fpm, I think that switching should be possible by using -u myuser as opposed to things like APACHE_RUN_USER.

[md5]

Derp: https://github.com/docker-library/php/blob/58775aa6924fcb854eb57315f019bbbf729c94d2/5.6/fpm/Dockerfile#L13

Looks like it already runs as www-data. Sorry for the false alarm!

[sagikazarmark]

Actually, I would rather reopen this as the master process still runs as root:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1 174384 18104 ?        Ss   11:02   0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf)
www-data     9  0.0  0.1 185184 24516 ?        S    11:02   0:00 php-fpm: pool www
www-data    10  0.0  0.1 190832 29812 ?        S    11:02   0:00 php-fpm: pool www

[yosifkit]

@sagikazarmark as far as I can tell that is identical to many installs on non-container systems running apache/php or fpm:

# from my system with host installed apache/php
$ ps aux | grep apache
root      2814  0.0  0.0 267996 16348 ?        Ss   Jul12   1:13 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start
apache    3952  0.0  0.0 269956 18288 ?        S    Aug01   0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start
apache    3970  0.0  0.0 270056 17640 ?        S    Aug01   0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start
apache    8069  0.0  0.0 197788  7088 ?        S    Jul31   0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start
apache    8172  0.0  0.0 270344 18732 ?        S    Jul31   0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start
apache    8173  0.0  0.0 269916 17868 ?        S    Jul31   0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start
apache    8175  0.0  0.0 269888 17652 ?        S    Jul31   0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start
apache    8176  0.0  0.0 269964 17744 ?        S    Jul31   0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start
apache   11306  0.0  0.0 270084 17584 ?        S    Aug03   0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start
apache   16977  0.0  0.0 269120 16780 ?        S    Aug02   0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start
apache   24479  0.0  0.0 269572 17996 ?        S    Aug03   0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start
apache   27083  0.0  0.0 270056 17764 ?        S    Aug02   0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start

[tianon]

and can be overcome by using --user www-data, if full-coverage is necessary:

$ dockr run -it --rm --user www-data php:fpm
[04-Aug-2016 18:09:04] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[04-Aug-2016 18:09:04] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
[04-Aug-2016 18:09:04] NOTICE: fpm is running, pid 1
[04-Aug-2016 18:09:04] NOTICE: ready to handle connections

[sagikazarmark]

Indeed. Actually I am not sure about this, because on side there is the security issue of running root inside the container, on the other side there is what you say. So what's the correct way of doing this? I read about security issues and recommendations to run processes with non-root UID.

[tianon]

I think it depends wholly on your use case and your threat model. For most typical use-cases, the existing behavior should be sufficient (especially if combined with user namespaces on the daemon, thus making root in the container non-root on the host). The extra paranoid will likely want to run as some arbitrary UID that isn't consistent, which should also be possible via "--user" (assuming file permissions are appropriately set to handle the change as well).

[sagikazarmark]

Great, thanks @tianon

[ibotty]

When running as root, it cannot run on many container installations, because some do only allow running non-root containers. I don't see the problem that could arise when running as www-data by default. Is there any drawback?

[tianon]

As it's written, the container will start as root and step down to www-data automatically (which is the same pattern most official images use). If you have stronger constraints than that, there shouldn't be anything preventing Docker's --user flag from working out-of-the-box.

[ibotty]

Unfortunately that makes running this image on openshift online harder than it needs to be. Kubernetes (which is the basis of openshift) will automatically try to run the image with the configured USER. That won't be allowed in some configurations and will need additional non-obvious configuration to specify the user to use.

I don't really see what the problem with running as www-data by default is. Is there any advantage in running as root?

[tianon]

The ability to adjust filesystem permissions, bind "privileged" ports, etc before becoming non-root are a couple examples.

[flylan]

As far as I know, the running mode of php-fpm is the leader follow model. It does not need tools like gosu. You can change the users of the php-fpm working process through the php-fpm-user and php-fpm-group parameters. In addition, when installing php-fpm on traditional servers, the management process is root, and the working process is run by other users, such as www.

Running the php-fpm management process directly as a non-root user will cause many problems, such as the inability to create a sock file and port binding

[flylan]

For the software running in the leader follow model, the management process only does the management work, unlike the working process, which will run the user code, so that the management process is safe, so it is safe to run as root user. The working process is different, because the working process will run the code of the user end, and the code of the user end may have vulnerabilities exploited by hackers. Some vulnerabilities can allow hackers to hack into the system, so it is necessary to run the working process as a non-root user, so even if the hacker hacks into the system, it can only be accessed as an ordinary user