php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #69658 session.save_path PHP_ADMIN_VALUE fastcgi_param Mode Not Parsed Correctly
Submitted: 2015-05-19 04:10 UTC Modified: 2015-05-31 04:22 UTC
Votes:6
Avg. Score:4.3 ± 0.9
Reproduced:5 of 5 (100.0%)
Same Version:3 (60.0%)
Same OS:1 (20.0%)
From: own3mall at gmail dot com Assigned:
Status: No Feedback Package: FPM related
PHP Version: 5.6.9 OS: Ubutun 15.04
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: own3mall at gmail dot com
New email:
PHP Version: OS:

 

 [2015-05-19 04:10 UTC] own3mall at gmail dot com
Description:
------------
If I setup a server entry in nginx which has the following section

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        location ~ \.php$ {
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /var/www/new$fastcgi_script_name;
                fastcgi_param PHP_ADMIN_VALUE "open_basedir=/var/www/new/:/tmp:/usr/share/php:/usr/share/pear:/usr/share/roundcube \n upload_tmp_dir=/tmp \n session.save_path=0;660;/var/www/php_sessions";
                include fastcgi_params;
        }

session.save_path is not parsed correctly.  When using session_save_path(), the path is set to "0".  For some reason, in nginx configuration files, the MODE set in PHP_ADMIN_VALUE for session.save_path is not processed correctly.  I would expect session_save_path() to return "/var/www/php_sessions" as it does in Apache when using this:

php_admin_value session.save_path 0;660;/var/www/php_sessions

It should not return "0" as the path.  It took me days to figure out why this wasn't working in nginx when it was working in apache.

Similar to bug #52609.  Problem is still occurring in php5-fpm package from Ubuntu 15.04.  Actual true version is:

PHP 5.6.4-4ubuntu6 (fpm-fcgi) (built: Apr 17 2015 15:47:47)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies

Test script:
---------------
Setup and install nginx and php5-fpm.  In /etc/nginx/sites-enabled/default, add this:

location ~ \.php$ {
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /var/www/new$fastcgi_script_name;
                fastcgi_param PHP_ADMIN_VALUE "open_basedir=/var/www/new/:/tmp:/usr/share/php:/usr/share/pear:/usr/share/roundcube \n upload_tmp_dir=/tmp \n session.save_path=0;660;/var/www/php_sessions";
                include fastcgi_params;
        }

Put a php file in the root with the following:

<?php
session_start();
echo "My session path is: " . session_save_path();
?>

Expected result:
----------------
When specified with a preceding MODE, the file permissions mode should be respected, and the session.save_path should return as defined "/var/www/php_sessions" rather than "0"

Actual result:
--------------
session.save_path is "0".

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-05-19 10:31 UTC] yohgaki@php.net
-Status: Open +Status: Feedback
 [2015-05-19 10:31 UTC] yohgaki@php.net
I'm not familiar with the applicable code, but 

session.save_path=0;660;/var/www/php_sessions";

you have ";" which indicates start of comment. 
Something like 

session.save_path=\"0;660;/var/www/php_sessions\"";

may work. Refer to Nginx manual for correct syntax.
 [2015-05-20 03:53 UTC] own3mall at gmail dot com
Yes, it appears that escaping the setting worked.  I guess it must be escaped in the nginx configuration.  Bug can be closed.
 [2015-05-31 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Nov 23 11:01:28 2024 UTC