Edit report at https://bugs.php.net/bug.php?id=62279&edit=1
ID: 62279
Comment by: graham at wyenet dot net
Reported by: nospam at bigalex dot it
Summary: PHP-FPM chroot never-solved problems (extends
#55322)
Status: Analyzed
Type: Bug
Package: FPM related
Operating System: Irrelevant
PHP Version: Any
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2012-07-04 17:08:10] f...@php.net
I used pseudo bash syntax but it'll be implemanted inside fpm (with C code)
------------------------------------------------------------------------
[2012-07-04 16:48:00] 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 10:38:14] f...@php.net
>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;
fi
done
or somehting more restrictive:
for var in "DOCUMENT_ROOT" "SCRIPT_FILENAME" "PATH_TRANSLATED"]; do
if ($_SERVER[$var] =~ /^$chroot(.*)$/); then
$_SERVER[$var] = $1;
fi
end
------------------------------------------------------------------------
[2012-06-28 17:45:34] 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-06-28 16:02:03] 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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=62279
--
Edit this bug report at https://bugs.php.net/bug.php?id=62279&edit=1
