Edit report at https://bugs.php.net/bug.php?id=62279&edit=1

 ID:                 62279
 Comment 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:

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! :)


Previous Comments:
------------------------------------------------------------------------
[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

Reply via email to