Bug #53611 [Com]: fastcgi_param PHP_VALUE pollutes other sites

Edit report at https://bugs.php.net/bug.php?id=53611&edit=1 ID: 53611 Comment by: mp at webfactory dot de Reported by: jraxis at gmail dot com Summary: fastcgi_param PHP_VALUE pollutes other sites Status: Open Type: Bug Package: FPM related Operating System: Linux PHP Version: 5.5.0 Block user comment: N Private report: N New Comment: The PHP_VALUE/PHP_ADMIN_VALUE feature was added in https://github.com/php/php-src/commit/34ba9e39fafa3a980a1b69285f68b0e12ad6b876. There is no clean-up, so the modified values persist in the PHP-FPM worker and affect the next request served. To reproduce this more easily, configure PHP-FPM with a single worker (pm = static, pm.max_children = 1). To work around it, - explicitly configure the same set of INI settings in all virtual hosts - configure FPM to only serve one request per worker - use ini_set() in PHP userland instead of using PHP_(ADMIN_)VALUE, although not possible for all settings Previous Comments: ------------------------------------------------------------------------ [2018-11-24 09:33:48] php-bugtracker at trash-me dot com Is there any chance, that this bug gets fixed anytime soon? IMHO that's a major problem for shared hosting environments, where multiple users share a common FPM-Pool. Settings from the vhost-configuration of one user might change settings on vhosts of other users in an unpredictable way. Especially, when working with sensitive settings, such as open_basdir, disable_functions or session.save_path, this bug leads to serious security issues. ------------------------------------------------------------------------ [2017-04-04 15:23:01] thciobanu at yahoo dot com I can confirm this issue is still valid for php 7.0.12 and 7.1.3. Excerpt from nginx.conf: location ~ \.php$ { root /var/www/html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~ _pre\.php$ { root /var/www/html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PHP_VALUE "auto_prepend_file=/var/www/html/die.php"; include fastcgi_params; } # cat /var/www/html/index.php <?php die("index\n"); # cat /var/www/html/die.php <?php die("foo\n"); and index_pre.php is just a symlink to index.php: # curl http://localhost/index.php index # curl http://localhost/index_pre.php foo # curl http://localhost/index.php foo ------------------------------------------------------------------------ [2016-03-02 05:39:57] kthunt at gmail dot com I have had the same experience using PHP 5.6.18 on CentOS 7.2.1511 as described. I got around the issue by giving each server {} it's own php-fpm.d pool in the line fastcgi_pass unix:/var/run/php-fpm/website.sock; This seemed to eliminate the cross talk. Now I have installed the SquirrelMail php webmail system and I get cross talk between the location /squirrelmail {...} block and location ~ \.php$ {...} block When handling a request for a location under /squirrelmail, it would give a file not found error for the "auto_prepend_file=..file.." from the location ~ \.php$ {...} block. I found a workaround as shown below by adding fastcgi_param PHP_VALUE "auto_prepend_file="; to the /squirrelmail block. Maybe there's a better standard way of getting each location's PHP_VALUE setting handled correctly. server { listen 80; server_name website.com; root /var/www/website.com/html; index index.php; location / { try_files $uri $uri/ =404; } location /squirrelmail { root /usr/share/; index index.php index.html index.htm; location ~ ^/squirrelmail/(.+\.php)$ { try_files $uri =404; root /usr/share/; fastcgi_pass unix:/var/run/php-fpm/website.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PHP_VALUE "auto_prepend_file="; include /etc/nginx/fastcgi_params; } location ~* ^/squirrelmail/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ { root /usr/share/; } } location ~ \.php$ { try_files $uri =404; fastcgi_pass unix:/var/run/php-fpm/website.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PHP_VALUE "auto_prepend_file=/var/www/website.com/core/lib.common.php"; include fastcgi_params; } } ------------------------------------------------------------------------ [2014-09-24 19:47:55] manuel-php at mausz dot at During migration from mod_php to FPM we stumbled across this too. So I've written a small patch which uses Zend INI to restore the altered INI settings after each request: diff -Naur php-5.5.16.orig/sapi/fpm/fpm/fpm_main.c php-5.5.16/sapi/fpm/fpm/fpm_main.c --- php-5.5.16.orig/sapi/fpm/fpm/fpm_main.c 2014-08-21 10:45:02.000000000 +0200 +++ php-5.5.16/sapi/fpm/fpm/fpm_main.c 2014-09-15 16:05:27.777482784 +0200 @@ -1405,7 +1405,6 @@ int *mode = (int *)arg; char *key; char *value = NULL; - struct key_value_s kv; if (!mode || !arg1) return; @@ -1416,7 +1415,7 @@ key = Z_STRVAL_P(arg1); - if (!key || strlen(key) < 1) { + if (!key || Z_STRLEN_P(arg1) < 1) { zlog(ZLOG_ERROR, "Passing INI directive through FastCGI: empty key"); return; } @@ -1430,10 +1429,7 @@ return; } - kv.key = key; - kv.value = value; - kv.next = NULL; - if (fpm_php_apply_defines_ex(&kv, *mode) == -1) { + if (zend_alter_ini_entry(key, Z_STRLEN_P(arg1) + 1, value, Z_STRLEN_P(arg2), *mode, PHP_INI_STAGE_HTACCESS) == FAILURE) { zlog(ZLOG_ERROR, "Passing INI directive through FastCGI: unable to set '%s'", key); } } ------------------------------------------------------------------------ [2013-11-19 17:24:08] andy at propcom dot co dot uk I have also experienced this. It seems that any ini settings changed with PHP_VALUE or PHP_ADMIN_VALUE environment variables are set for the life of the worker thread by fpm_php_zend_ini_alter_master. Perhaps the old values of the altered settings could be saved and restored on request completion? ------------------------------------------------------------------------ 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=53611 -- Edit this bug report at https://bugs.php.net/bug.php?id=53611&edit=1