Start PHP-FPM with root option automatically
I was trying to get PHP-FPM running a pool as root, but I can’t seem to adjust the init.d startup params. It works when starting PHP-FPM from the CLI (with sudo php-fpm7.0 -DRy /etc/php/7.0/fpm/php-fpm.conf , but I can’t get this to work with the service command ( sudo service php7.0-fpm (re)start . So Everytime the server reboots, PHP-FPM fails and I would have to run this command. I have tried to place a file «php-fpm7.0″ in /etc/default with the line DAEMON_ARGS=»—daemonize —fpm-config $CONFFILE -R» , and I even tried add the -R parameter to the do_start function in /etc/init.d/php7.0-fpm directly, but I keep getting the please specify user and group other than root error. Is there any way I can get this working on startup and with the service command? Off topic: I know all the risks and I know why I shouldn’t do it, but I want to anyway. I need to run some scripts to create directories, performing chown commands etc. and the pool will be dedicated to a backend used by an nginx server block which is reachable from within the private 192.168.1.X network only on one specific URL path. As an alternative I could set up a cron script which executes a PHP script as root, but that approach would cost me a lot more hours.
2 Answers 2
On systemd systems, you may have to configure this via systemd rather than system V init scripts
The below steps are tested and working on Ubuntu 16.04 LTS. And this is your culprit for redirected init scripts:
/lib/lsb/init-functions.d/40-systemd 1. Edit your php-fpm pool configuration e.g. /etc/php/7.0/fpm/pool.d/www.conf and configure root as the user/group as root
; Unix user/group of processes ; Note: The user is mandatory. If the group is not set, the default user's group ; will be used. user = root group = root
2. Edit /lib/systemd/system/php7.0-fpm.service and append -R to the ExecStart variable to allow the service to run as root
ExecStart=/usr/sbin/php-fpm7.0 --nodaemonize --fpm-config /etc/php/7.0/fpm/php-fpm.conf -R
3. Reload the configuration
4. Start the service
5. Check it out
$ ps auwx | grep php root 32061 0.0 0.0 221680 26084 ? Ss 16:59 0:00 php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf) root 32063 0.0 0.0 221680 4992 ? S 16:59 0:00 php-fpm: pool www root 32064 0.0 0.0 221680 4992 ? S 16:59 0:00 php-fpm: pool www
I finally found a solution. It turned out Ubuntu was using systemd to start and restart PHP-FPM and was therefor ignoring the init.d files.
If you experience issues with adjustments to init.d files being ignored and you’re on Ubuntu 15.04 or later, big chance that service has a systemd service file as well.
So the fix for my problem: My system has a file named /lib/systemd/system/php7.0-fpm.service , which is used by systemd . With the command cat /lib/systemd/system/php7.0-fpm.service you can see the content of the service file. You replace php7.0-fpm.service with the name of your service file. PHP7.0-FPM’s service file looks like this:
[Unit] Description=The PHP 7.0 FastCGI Process Manager Documentation=man:php-fpm7.0(8) After=network.target [Service] Type=notify PIDFile=/run/php/php7.0-fpm.pid ExecStart=/usr/sbin/php-fpm7.0 --nodaemonize --fpm-config /etc/php/7.0/fpm/php-fpm.conf ExecReload=/bin/kill -USR2 $MAINPID [Install] WantedBy=multi-user.target In my case I needed to adjust the ExecStart rule. We don’t have to edit this file, because systemd offers a way to override specific rules. The command sudo systemctl edit php7.0-fpm.service will open up an editor where you can enter those rules. Just enter the section(s) of the rule(s) you want to adjust and save the file. In my case it looks like this:
[Service] ExecStart= ExecStart=/usr/sbin/php-fpm7.0 --allow-to-run-as-root --nodaemonize --fpm-config /etc/php/7.0/fpm/php-fpm.conf Make sure to reset the rule you want to edit first, otherwise both rules will be executed. Also make sure to run sudo systemctl daemon-reload after saving this file. In my case running pools as root is now allowed on Ubuntu 16.04.
Saved searches
Use saved searches to filter your results more quickly
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run php:fpm as non-root #70
Run php:fpm as non-root #70
Comments
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.
The text was updated successfully, but these errors were encountered:
Looks like it already runs as www-data . Sorry for the false alarm!
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 @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 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
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.
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).