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

From: Date: Tue, 04 Apr 2017 15:23:07 +0000
Subject: Bug #53611 [Com]: fastcgi_param PHP_VALUE pollutes other sites
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-208316@lists.php.net to get a copy of this message
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


Thread (18 messages)

« previous php.bugs (#208316) next »