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:
Present at least in PHP 7.2.19. Of course, as it's FPM-related, it does not only affect nginx
at in the OP's comment, but also Apache setups.
Additional workaround solution: Use PHP_VALUE only for PHP_INI_SYSTEM settings and make sure you
configure the same set of those in all virtual hosts. Use .user.ini files for all the rest. Values
from .user.ini are cleaned up as one would expect.
Previous Comments:
------------------------------------------------------------------------
[2019-07-12 21:45:19] mp at webfactory dot de
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
------------------------------------------------------------------------
[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);
}
}
------------------------------------------------------------------------
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