|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #62279 PHP-FPM chroot never-solved problems (extends #55322)
Submitted: 2012-06-09 17:43 UTC Modified: 2017-02-02 12:06 UTC
Avg. Score:4.8 ± 0.5
Reproduced:24 of 25 (96.0%)
Same Version:14 (58.3%)
Same OS:19 (79.2%)
From: nospam at bigalex dot it Assigned:
Status: Open Package: FPM related
PHP Version: Any OS: Irrelevant
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2012-06-09 17:43 UTC] nospam at bigalex dot it
Since PHP-FPM is the one taking care of the chroot, I think the problems related 
to inconsistent variables should be solved here.

In fact, even if the environment is chrooted, the following variables still give 
the unchrooted content:


I don't think this behaviour has to be solved by apache, nginx, lighttpd or any 
other web server, since the web server is not chrooted, instead it is connecting 
to PHP-FPM process through (tcp) sockets; for this reason I am working on a 
patch to fix this behaviour and in case the bug will be accepted, 
I will be happy to share the solution with you ;-)

I've already looked for a solution or a bug request about it, and the bug #55322 
is already about this problem; my analysis however is deeper than the other 
because the variables seems to be three and not just one.
The proposed "fix" to symlink the real path into the chroot isn't clean, so I 
think this should be resolved here, inside php-fpm, and not with some weird 

Test script:
Inside a pool, I use the chroot feature, this way:

chroot = /home/vhosts/h0001

expecting the scripts would be allowed to be executed with the chroot environment in mind, so the variables SCRIPT_FILENAME, PATH_TRANSLATED, DOCUMENT_ROOT should be changed accordingly before the script being executed (so their value should be the one into the chroot environment).

Expected result:
As an example, the value $_SERVER["PATH_TRANSLATED"] should be 

Actual result:
As an example, the value $_SERVER["PATH_TRANSLATED"] is 


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-06-09 17:45 UTC] nospam at bigalex dot it
Edited the php version, since it affects avery version.
 [2012-06-09 17:45 UTC] nospam at bigalex dot it
-PHP Version: 5.4Git-2012-06-09 (Git) +PHP Version: Any
 [2012-06-24 16:25 UTC] nospam at bigalex dot it
I want to patch the sources, but can't find a way to get from the function 
init_request_info info fpm_main.c the chroot path.
Since the documentation about it lacks, can anyone put me in the right 

I think I need to get the configuration (or add a variable to the worker) about 
the current chroot location. A more safe way to handle it would be to get, from 
the father process, the child's chroot location and filter it before passing the 
variables to the child.

Anyway, in both cases, there is lack of documentation and I've still been unable 
to patch anything, so suggestions would be really appreciated! :)
 [2012-06-28 16:02 UTC] graham at wyenet dot net
The symbolic trick does work (as long as the sym link is relative (ie ../../../chrootpath if you try to link directly from the root, then the symlink goes outside the jail and it will still fail).

Anyway thats a very messy hack, and I agree with you, php-fpm creates the jails, so it should fix the PHP variables.

Without the symlink, I just get file not found for all calls for scripts. 

If you change fix.cgi_pathinfo = 0 it will run the scripts, but the $_SERVER variables will still be wrong... Im sure most people would rather it was fixed so that the fix.cgi_pathinfo = 1 works, AND the variables are set correctly... But either way would be better than trying to hack in fixes with sym links, and/or preloading a fixup script.

I did take a look at the fpm_main.c but also been unable to create my own patch for it at this time. Surely it cant be that hard to read the chroot path from the configuration file, and remove that from all appropriate server variables, or recreate the broken variables some other way.

Symlink is good enough for a test environment, to see what other php functions break with the chroot, and to start building a system, but I wouldn't use that hack on a production web server.
 [2012-06-28 17:45 UTC] nospam at bigalex dot it
In the meantime, I've already found a way to fix this behaviour: a proxy between 
PHP-FPM and Apache.

I needed a caching proxy to be on top of Apache to cache php scripts (I don't care 
about static files because what really causes CPU and memory problems is having 
the php processes running), so I've thought to implement a fcgi proxy to be used 
among PHP-FPM and Apache.

It does work and does a great job: I didn't need to implement anything about the 
HTTP protocol since there's already Apache caring about it; then, caching the 
results from PHP, I can avoid asking FPM to run the already cached pages, giving 
them away to Apache in an elegant manner. And, of course, the proxy does fix the 
wrong variables, removing the chrooted part and making the scripts able to work.

I'm still trying to fix the sources, but since they appears complicated (read: 
messy), and there's no documentation about it or about debugging them, I don't 
think I will fix them before I have more time to spend or having a clue about 
reading the configuration values from fpm_main.c.

Anyway, for anyone interested in it, the proxy has been made using python and flup 
server and client implementations.
 [2012-07-04 10:38 UTC]
-Status: Open +Status: Analyzed -Assigned To: +Assigned To: fat
 [2012-07-04 10:38 UTC]
From my point of view, I'd rather prefer to configure this on the web server 
side (if it's not possible with apache then switch to something else -- aka 
nginx for exemple. If apache does not suit well with fastcgi customizations, 
then ask apache guys :p)

more seriously, I can understand the need. I'll try to look at this to 
dynamicaly adapt fastcgi variables from the chroot env. The following algorithm 
should work:

for variable in  all_fastcgi_variables; do
  if ($_SERVER[$var] =~ /^$chroot(.*)$/); then
    $_SERVER[$var] = $1;

or somehting more restrictive:

  if ($_SERVER[$var] =~ /^$chroot(.*)$/); then
    $_SERVER[$var] = $1;
 [2012-07-04 16:48 UTC] nospam at bigalex dot it
Thank your for your support but I'm sorry, I think I didn't understand your fix: 
does php-fpm chroot works starting it from bash, or how could it be implemented 
the way you said (from inside fpm I mean)?
 [2012-07-04 17:08 UTC]
I used pseudo bash syntax but it'll be implemanted inside fpm (with C code)
 [2012-07-19 00:44 UTC] graham at wyenet dot net
Moving to nginx would be lovely, but on many low cost virtual hosting scenarios where a dedicated server would be totally overkill, many end users are still heavily using .htaccess files (Yes I know the arguments against.. performance, excessive stats,  too many reads etc etc...)

Take just about any off the shelf, wordpress, drupal, magento etc, and it comes ready to roll on Apache, and fully loaded with .htaccess files.

The argument against changing it from the Apache side of things, is that Apache has simply followed the standards for FastCGI, and that since its PHP-FPM that has created the jail, Apache doesnt even need to know that its happened.

Your proposed solution to the problem should sort it out though, I assume it would also avoid the "not found" problem when fix.cgi_pathinfo is set to 1.

If you have a patch, Im quite happy to try it on one of my systems to check it corrects the problem in various "off the shelf" configurations, and if any problems still occur, im happy to share the config file.

PHP-FPM works brilliantly with Apache / FastCGI with sockets.. but would be nice to get the chroot working without resorting to symlink workarounds etc.
 [2013-10-26 16:16 UTC] admin at franceserv dot fr
More 1 year (15 month) after the last comment, i have the same problem and i don't think this bug is solved.

Everybody have migrate to Nginx instead Apache ? I can't do it because my hosted need to use .htaccess for Apache.

Thanks so much for your reply ...
 [2016-11-29 15:15 UTC] sjon at hortensius dot net
This was partially fixed in #69090
 [2017-02-02 11:00 UTC] ghosh at pw6 dot de
#69090 has nothing to do with this bug. This bug still exists in 7.1.
 [2017-02-02 12:06 UTC]
-Status: Analyzed +Status: Open -Assigned To: fat +Assigned To:
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC