23

I know the risks about running php-fpm as root. However there are situations where one would need to do it, like appliances, accessing operating system resources or even for testing purposes.

I have tried to change the user and group of php-fpm.d/www.conf to root when I restart the php-fpm process it raise an error:

Starting php-fpm: [26-Jun-2014 00:39:07] ERROR: [pool www] please specify user and group other than root
[26-Jun-2014 00:39:07] ERROR: FPM initialization failed
[FAILED]

What should I do. Anyone help?

Ryker.Wang
  • 757
  • 1
  • 9
  • 18

5 Answers5

65

See:

# php-fpm --help
...
 -R, --allow-to-run-as-root
               Allow pool to run as root (disabled by default)
ex-nerd
  • 1,317
  • 12
  • 19
  • 2
    I'm not sure what you mean by "link". I provided a shell command for reference and the relevant section of the resulting output. If the output of the command changes, then the relevant section of the results will be different and that's exactly what you want to see (e.g. -R might no longer work to allow a pool to run as root). Maybe I wasn't completely clear that it's a shell command but that format is pretty standard notation to indicate a bash command. – ex-nerd Nov 02 '14 at 05:41
  • 3
    If anyone is looking to run this with their config, use `-y`: `php-fpm -y /etc/php-fpm.conf -R` will use your existing config and start the daemon in the background. – Brad Apr 02 '15 at 16:22
  • I believe your answer is not complete enough, neither php-fpm nor php7.4-fpm --help are working. This solved my problem: https://serverfault.com/questions/788669/start-php-fpm-with-root-option-automatically – Oriol Vilaseca May 19 '23 at 12:18
3

Just adding -R (like this ans. suggests) to your command may not work. It depends how your running the command to start php-fpm.

If you're using service php-fpm restart and it's using /etc/init.d instead of systemctl (see here), then you'll have to add -R to the DAEMON_ARGS variable located in the /etc/php/<phpversion>/fpm/php-fpm.conf script. (This variable is used in the do_start() function. See here).

If it's using systemctl then you'll have to edit the script used by systemctl which should be located in /lib/systemd/system/<phpversion>-fpm.service. Append -R to the ExcecStart variable. Then run systemctl daemon-reload and systemctl start php<version>-fpm (See here)

I used the following questions/answers/resources to help me compile this solution.

  1. https://serverfault.com/a/189961
  2. https://serverfault.com/q/788669
  3. https://stackoverflow.com/a/52919706/9530790
  4. https://serverfault.com/a/867334
  5. https://www.geeksforgeeks.org/what-is-init-d-in-linux-service-management/
shmuels
  • 1,039
  • 1
  • 9
  • 22
1

These 3 steps will fix the error.

  1. Locate php-fpm.service. For me it's /usr/lib/systemd/system/php-fpm.service. If you're not sure where it is, type find / -name php-fpm.service.
  2. Append -R to the ExecStart variable. Eg ExecStart=/usr/sbin/php-fpm --nodaemonize -R.
  3. Restart php-fpm. If systemctl restart php-fpm throws an error, run systemctl daemon-reload.

To anyone else wondering how to make php run as root, you also need to modify /etc/php-fpm.d/www.conf or modify a copy of it. Both user and group need to be changed to root. If you've made a copy of www.conf, you'll also need to modify this line listen = /run/php-fpm/www.sock.

Dan Bray
  • 7,242
  • 3
  • 52
  • 70
0

By default, php-fpm is shipped with a "www.conf" that contains, among others, the default www-data user configuration:

[www]
user = www-data
group = www-data

So, you need to create another file, loaded after www.conf, that will overwrite that default config. For example, create a file docker.conf in the same path as your php-fpm's Dockerfile and containing the following:

[www]
user = root
group = root

Then, in your Dockerfile, inject that file in your container with a name that will be loaded after the default www.conf:

COPY ./docker.conf /usr/local/etc/php-fpm.d/zzz-docker.conf
Alain Tiemblo
  • 36,099
  • 17
  • 121
  • 153
-24

Update 2018

Running it within a container is a possible valid reason to run php-fpm as root. It can be done by passing the -R command line argument to it


Original answer:

However there are situations where one would need to do it, like appliances, accessing operating system resources

You never need to do it. That's it. If you are managing system resources, grant permissions for the php-fpm user to that resources rather than running the whole process as root. If your question would be more specific I could show how to do that in a certain situation.

hek2mgl
  • 152,036
  • 28
  • 249
  • 266
  • For example, I need to 'cat /etc/shadow' which permission shows as ----------. 1 root root, I have no right to change it by using chmod. and when i use other user to running php-fpm, when a php script do system("cat /etc/shadow"), it return Permission denied. – Ryker.Wang Jun 25 '14 at 09:24
  • You could create a group `shadow_readers` and put the `php-fpm` user into that group. Then `sudo chown root:shadow_readers /etc/shadow` and `sudo chmod g+r /etc/shadow` – hek2mgl Jun 25 '14 at 09:28
  • I have no right to do any operating to the file such as chmod – Ryker.Wang Jun 25 '14 at 09:29
  • Then you will never have a chance to run *anything* as root – hek2mgl Jun 25 '14 at 09:30
  • 7
    This is not a valid answer to the question. There are times where php-fpm should be given root privileges. For example, I have a single-user linux VM set up behind NAT (all port forwarding is only done from my loopback adapter). This VM shares dirs with the Win32 VM host, and the utility which shares the resource requires all files to be owned by root:root on the linux guest OS. Only solution is for php5-fpm to also run as root in order to be able to read/write to files/directories in the shared location. This is a perfectly fine use-case for running php5-fpm as root. – Sam Levin Jan 20 '15 at 01:45
  • 3
    Same as: "I did `chown -R root:root /` , now vim can only run as root." – hek2mgl Jan 20 '15 at 13:11
  • 4
    @Sam: Sometimes the best answer to "how do I X?" is very *much* "don't **ever** do X !". Consider things like writing an accounting package in BCPL. Or an operating system in COBOL. Or pretty much *anything* in Perl (pax ducks for cover). Running vast complicated processes as root is an incredibly bad idea. If the process needs some super-powers, give it execute access to a very tightly controlled executable that can do it instead (and that's *all* it can do). Locking down a small, tightly controlled executable is far easier than locking down a vast behemoth. – paxdiablo Oct 09 '15 at 02:09
  • 3
    Re: "don't **ever** do X!" I believe that this is sometimes valid, but in this context, where the utility in question provides a command line flag called `--allow-to-run-as-root`, the highest voted answer is correct and should be accepted. – trey-jones May 31 '16 at 18:35
  • @threeve Why do you need it to run as root? (note that even apache/nginx are not running as root) I don't see a reason why a development server (by self-description) should run as root. And it never needs to do if you have a proper development environment. That's what my answer is saying. – hek2mgl May 31 '16 at 18:49
  • 4
    @hek2mgl My particular use case is a docker container where php-fpm needs to write to a mounted directory. There are probably others. Again, if the utility exposes a method of doing so easily, why shouldn't that be the accepted answer? – trey-jones May 31 '16 at 18:58
  • @threeve I would like to give an advice in your particular use but I won't here in comments because I simply don't know enough about it and I don't say it is always a simple solution. I can only clearly say that you'll never release a software in a halfway organized company that requires a web server to run as root. That's for sure. I mean your use case sounds like you are about to not only do this in development (where php -s is meant for) but also in production. I encourage you to ask a question on serverfault or superuser.. – hek2mgl May 31 '16 at 19:06
  • @threeve Another thing. While I would have not implemented the "don't run as root restriction" at all, there must be a reason why PHP developers decided so. I would simply leave it up to the user to do that or not, or better saying shoot in his own feet or not. (I mean you *can* run apache as root if you want, for example).. However, I can't say why they then added the `-R` option.. That makes no sense imo!! I only say, don't run a web server as root. – hek2mgl May 31 '16 at 19:09
  • @hek2mgl I certainly wouldn't do it in production! For a dev box, what does it matter? It's the easiest path to a "reasonable facsimile of production". – trey-jones May 31 '16 at 19:32
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/113450/discussion-between-hek2mgl-and-threeve). – hek2mgl May 31 '16 at 19:36
  • 2
    @hek2mgl what a senseless discussion, just because you can't imagine a scenario where something is valid doesn't mean there is none - even if the only valid scenario would be someone being in the lab doing an experiment for a white paper (and there most certainly always are more valid scenarios). I would consider deleting this "non-" answer. Stuff like this makes stackoverflow really troublesome to read. – Jey DWork Jan 15 '17 at 16:49
  • That's totally ok to run php-fpm as root in a container that has only purpose to run php-fpm. – Vedmant May 14 '18 at 10:15
  • @Vedmant I agree that running it in a container as root is a valid reason and I've changed my answer. In 2014 when this answer was posted, containers were not as trendy as today. Also please note that the opener of *this* questions, which I answered, was not running it in a container meaning they had no good reason to run it as root. – hek2mgl May 14 '18 at 10:44
  • Downvote wrong answers - leave a comment explaining why they're wrong if you wish. Wrong answers aren't 'purged' from Stack Overflow if they are an attempt to answer the question (and aren't, e.g. duplicates of other answers, spam, plagiarism, etc.). [From Review](https://stackoverflow.com/review/low-quality-posts/28350210). – Wai Ha Lee Feb 18 '21 at 06:35