|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65100 Reject root run
Submitted: 2013-06-23 03:36 UTC Modified: 2013-06-24 16:41 UTC
From: admin at mvpro dot net Assigned: fat (profile)
Status: Closed Package: FPM related
PHP Version: 5.5.0 OS: Linux Debian Wheezy
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: admin at mvpro dot net
New email:
PHP Version: OS:


 [2013-06-23 03:36 UTC] admin at mvpro dot net
Php5-fpm rejected to run with user 'root' and group 'root', it fails to load.

While proccess priority was implemented, i assume, running PHP-fpm with user 
'root' should be allowed.

Test script:
Put in /etc/php5/fpm/pool.d/www.conf

user = root

Expected result:
Success run.

Actual result:
Fail to run.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-24 00:03 UTC]
-Status: Open +Status: Assigned -Assigned To: +Assigned To: fat
 [2013-06-24 16:13 UTC]

I'm using Ubuntu 13.04 and I've compiled PHP 5.5 with FPM from sources.
I do indeed get something like this:
[24-Jun-2013 18:09:32] ERROR: [pool default] please specify user and group other than root
[24-Jun-2013 18:09:32] ERROR: FPM initialization failed

but I don't think it is a bad thing.
Running PHP with root as user would be considered a major security issue so maybe it's not really a bug.

Can you provide a real use case where you'd want to allow a script executed via FPM to have root privileges as I can't think of a good one right now?

 [2013-06-24 16:21 UTC] admin at mvpro dot net
dlsniper, i have nothing against such policy, however it would be interesting to 
know what issues can it do. I have many scripts which can not get access to php 
files because of bad chmod. I can set it automatically but it's rather bad to do 
it via cron every minute, because it will affect perfomance. Also it will not 
'at the moment', maybe user have to wait for a minute after a file update. It's 
not really awesome.

I think it's a bug because in PHP 5.5 there are invent:

"; Specify the nice(2) priority to apply to the master process (only if set)
; The value can vary from -19 (highest priority) to 20 (lower priority)
; Note: - It will only work if the FPM master process is launched as root
;       - The pool process will inherit the master process priority
;         unless it specified otherwise
; Default Value: no set
process.priority = -19"

This new feature is useless, when root user cause fail to load php-fpm. If root 
issue is permanent, then why is proccess.priority was implemented?
 [2013-06-24 16:29 UTC]

I've forgot to mention that if you run: php-fpm help
it will show you something like this:
Usage: php-fpm [-n] [-e] [-h] [-i] [-m] [-v] [-t] [-p <prefix>] [-g <pid>] [-c <file>] [-d foo[=bar]] [-y <file>] [-D] [-F]
  -R, --allow-to-run-as-root
                   Allow pool to run as root (disabled by default)

Have you tried that?

Thanks :)
 [2013-06-24 16:37 UTC] admin at mvpro dot net
-Status: Assigned +Status: Closed
 [2013-06-24 16:37 UTC] admin at mvpro dot net
Umm, ok with -R it's OK.

It's not the best way to modify /etc/init.d fpm files manually, so ideally i think 
you should allow root by default. You should change type of root message to 
warning. I am sure you need to inform users about the issue with root, but it 
should not make php5-fpm fail to start.
 [2013-06-24 16:41 UTC] admin at mvpro dot net
Proccess priority works...i am stupid, sorry.

 [2015-11-08 22:09 UTC] jchrist at datto dot com

We also need to use this feature.  I am using php5-fpm version PHP 5.3.10-1ubuntu3.21.  when I run /etc/init.d/php5-fpm help.  I do not get the -R option.  Can you please help me?


Fury Christ
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu May 30 11:01:31 2024 UTC