Bug #63965 [Asn->Opn]: php-fpm site-specific settings go global
Edit report at https://bugs.php.net/bug.php?id=63965&edit=1
ID: 63965
Updated by: kalle@php.net
Reported by: markku dot niskanen at gmail dot com
Summary: php-fpm site-specific settings go global
-Status: Assigned
+Status: Open
Type: Bug
Package: FPM related
Operating System: Centos 6.2
PHP Version: 5.3.20
-Assigned To: fat
+Assigned To:
Block user comment: N
Private report: N
Previous Comments:
------------------------------------------------------------------------
[2015-07-24 20:20:09] butesa at freenet dot de
This is not only about vhosts. Consider the following Apache configuration:
AddHandler proxy:fcgi://localhost:9000 .php
<Directory "/var/www/test2/">
SetEnv PHP_VALUE max_execution_time=1
</Directory>
If a php process handles a request for /var/www/test2/, it will remember the setting and apply it to
other requests too. But with the config above, you obviously want to apply the setting only to this
one directory.
I think the right thing do to is revert all PHP_VALUE changes after each script execution, so the
php process has the original settings when it accepts the next request.
------------------------------------------------------------------------
[2013-11-19 17:11:35] andy at propcom dot co dot uk
This seems to be a duplicate of bug 53611
------------------------------------------------------------------------
[2013-05-20 14:29:16] 63965 dot phpbug at tomvalentine dot net
PS. I wrote up a test script to test the settings on my PHP server:
http://tomvalentine.net/misc/socket.php.txt
------------------------------------------------------------------------
[2013-05-20 14:22:07] 63965 dot phpbug at tomvalentine dot net
The problem with this is that when setting a value through fastcgi_param PHP_ADMIN_VAlUE (or
PHP_VALUE) is that when php-fpm receives this value it is applied only to the child process that
receives the request.
E.g. you have a pool of 5 processes, only one of thoses processes gets the value when the request is
passed to it. When the child process is restarted (after max requests or max time) it loses the
PHP_ADMIN_VALUE.
The side effect of this is some unpredictability as by requesting info.php from another server
block, depending on which child process serves out info.php, you may get different results.
PHP-FPM also has rubbish security as any FCGI client can pass requests to it by default. E.g. nginx,
php/python/perl scripts
You can sometimes limit who can access the php-fpm server by:
- If running as a unix domain socket, set listen.owner & listen.group to the user and group of
the webserver which will not work if php-fpm and webserver are running as the same user and group.
And set listen.mode to 0600 so that only the specified user can connect to it (renders listen.group
pointless)
However from fpm.conf "Many BSD-derived systems allow connections regardless of
permissions."
- If php-fpm is listening as a TCP server then you have to use a firewall to limit the connections
between FCGI client and PHP-FPM (even if it is through localhost)
Other similar bugs: 53611 & 54309
------------------------------------------------------------------------
[2013-04-19 10:42:54] steven dot hartland at multiplay dot co dot uk
This is a very nasty security risk, with settings applied to trusted hosts being
leaked to other vhosts.
It essentially means that if PHP_VALUE or PHP_ADMIN_VALUE is used then every value
set must then be explicitly set for every vhost otherwise the settings leak.
This will also cause random behaviour dependent on request order.
This should be reclassified as security and FPM module
------------------------------------------------------------------------
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=63965
--
Edit this bug report at https://bugs.php.net/bug.php?id=63965&edit=1
Thread (9 messages)