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

[email protected] ("thciobanu at yahoo dot com")
Newsgroups php.bugs
Message-ID <[email protected]>
Edit report at https://bugs.php.net/bug.php?id=53611&edit=1

 ID:                 53611
 Comment by:         thciobanu at yahoo 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 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


Previous Comments:
------------------------------------------------------------------------
[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?

------------------------------------------------------------------------
[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.

------------------------------------------------------------------------


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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.