Bug #63965 [Com]: php-fpm site-specific settings go global

From: Date: Fri, 07 Jul 2023 06:18:35 +0000
Subject: Bug #63965 [Com]: php-fpm site-specific settings go global
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-244895@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=63965&edit=1 ID: 63965 Comment by: Apsaraofdelhi at gmail dot com Reported by: markku dot niskanen at gmail dot com Summary: php-fpm site-specific settings go global Status: Open Type: Bug Package: FPM related Operating System: Centos 6.2 PHP Version: 5.3.20 Block user comment: N Private report: N New Comment: I Am Apsara Sharma Living in Dehradun If you are looking for independent model girls for your fun and enjoyment then contact my website. visit for more at Dehradunescort.org 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

« previous php.bugs (#244895) next »