Edit report at https://bugs.php.net/bug.php?id=53611&edit=1
ID: 53611
Comment by: kthunt at gmail dot com
Reported by: jraxis at gmail dot com
Summary: fastcgi_param PHP_VALUE pollutes other sites
Status: Re-Opened
Type: Bug
Package: FPM related
Operating System: Linux
PHP Version: 5.5.0
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
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;
}
}
Previous Comments:
------------------------------------------------------------------------
[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?
------------------------------------------------------------------------
[2013-11-19 17:11:35] andy at propcom dot co dot uk
Related To: Bug #63965
------------------------------------------------------------------------
[2013-10-21 11:06:17] notvalid at example dot com
I've also experienced this, but only once during my initial php-fpm setup. It seems it may be
related to graceful reconfiguration or FD re-use as I've not experienced it since stabilizing
the configs.
It was rather worrisome as due to the values I was passing (php_admin_value open_basedir,
disable_functions, etc), the site that received the polluted values ceased to function.
------------------------------------------------------------------------
[2013-07-08 23:04:53] yohgaki@php.net
I think this is applicable to any versions. Updated version and re-opened.
------------------------------------------------------------------------
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