Edit report at https://bugs.php.net/bug.php?id=62279&edit=1
ID: 62279 Updated by: f...@php.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: I used pseudo bash syntax but it'll be implemanted inside fpm (with C code) Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [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! :) ------------------------------------------------------------------------ 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