Edit report at https://bugs.php.net/bug.php?id=62279&edit=1
ID: 62279
User updated by: nospam at bigalex dot it
Reported by: nospam at bigalex dot it
Summary: PHP-FPM chroot never-solved problems (extends
#55322)
Status: Open
Type: Bug
Package: FPM related
Operating System: Irrelevant
PHP Version: Any
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2012-06-24 16:25:15] 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
direction?
:P
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-09 17:45:35] nospam at bigalex dot it
Edited the php version, since it affects avery version.
------------------------------------------------------------------------
[2012-06-09 17:43:39] nospam at bigalex dot it
Description:
------------
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:
$_SERVER["SCRIPT_FILENAME"]
$_SERVER["PATH_TRANSLATED"]
$_SERVER["DOCUMENT_ROOT"]
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
workarounds.
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
/home/domains/test.com/phpinfo.php
Actual result:
--------------
As an example, the value $_SERVER["PATH_TRANSLATED"] is
/home/vhosts/h0001/home/domains/test.com/phpinfo.php
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=62279&edit=1
