Inconsistent behaviour of include_path set with php

Inconsistent behaviour of include_path set with php_value

Bug #43677

Inconsistent behaviour of include_path set with php_value

Submitted:

2007-12-26 01:47 UTC

Modified:

2008-03-13 16:01 UTC

Votes:	124
Avg. Score:	4.9 ± 0.4
Reproduced:	114 of 114 (100.0%)
Same Version:	112 (98.2%)
Same OS:	34 (29.8%)

From:

root at net1 dot cc

Assigned:

Status:

Closed

Package:

Safe Mode/open_basedir

PHP Version:

5.2.5

OS:

FreeBSD 6.2

Private report:

CVE-ID:

None

[2007-12-26 01:47 UTC] root at net1 dot cc

Description:
------------
PHP randomly assigns for the local include_path value the global one, not the one set with php_value, and, when it does assign the global value, it does not allow to use ini_set() to modify it (behaves like it was set with php_admin_value).

Reproduce code:
---------------
My default include path is ".:/usr/local/share/pear". In the httpd.conf (btw, this is Apache 2.2.x), I have:
php_value include_path .:/blabla
There's a file 'test.php' which contains the following:
<?php phpinfo(); ?>




Expected result:
----------------
I open the test.php in a web browser and keep refreshing it. I expect it to show:
include_path .:/blabla
each time i refresh it

Actual result:
--------------
The results are random, once it shows:
include_path .:/blabla
once it shows:
include_path .:/usr/local/share/pear

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2008-01-06 21:38 UTC] d at tpyo dot net

Noticed the same thing with 5.2.5 on Linux w/ Apache 2.  I'm aware 
this is supposed to be the intended behaviour as of 5.2.5 but 
something is definitely breaking.

It seems the include_path is being unset or ignored at some point.  
Haven't experienced this at random as described - once it breaks it 
doesn't correct itself until restarting Apache.

Could be linked to the fix for bug #41561?

[2008-01-07 22:57 UTC] root at net1 dot cc

Digging some more into that, I've found the problem to be in the Apache/PHP interpretation of the configured VirtualHost.

First, the problem only exists if we do have *both* VirtualHost(s) with 'php_admin_value include_path' *and* another VirtualHost(s)with 'php_value include_path'. If all our VirtualHosts use 'php_value' only, it's behaving as usual.

Experimenting with this shows that, after an Apache startup/reload, things work OK. Then, they start to randomly fail until some time later 100% of the requests fail to work OK.

Looking at the Apache logs, the problem (according to me) is that the PHP module behaves strange when it sees the php_admin_value variable. Let's say we have this config (not a working one, just to give you the idea):
<VirtualHost *:80>
ServerName test1.dot.com
php_value include_path .:/test1
</VirtualHost>
<VirtualHost *:80>
ServerName test2.dot.com
php_admin_value include_path .:/test2
</VirtualHost>
We fire up Apache, and start accessing test1.dot.com pages *only*. Everything works fine. *But* when we start to simultaneously access test2.dot.com, the test1.dot.com pages start to fail more and more (due to the incorrect include_path). Monitoring which Apache process servers each page reveals that *when* a process serves a page for test2.dot.com, it reads the 'php_admin_value' for it, sets it up, and refuses to change the include_path from further config lines, *even* if they are from the config of the virtual host of a *new* request. That is - once an Apache process servers a page for a VirtualHost with php_admin_value, all consequent requests served by the same process are processed with that php_admin_value, regardless of their config.

The *solution* , though insecure, is to change *all* your 'php_admin_value include_path' lines to 'php_value include_path'.

I would very much like to see this fixed (though I'm completely unaware of the way Apache/PHP configuration is parsed), and will provide more feedback if needed.

[2008-01-12 18:08 UTC] manuel at mausz dot at

I tracked the problem down. Every altered ini setting gets added to the  modified_ini_directives-hashtable in order to restore the original value after the request has been processed. Zend simply forgets to restore the modifiable-level.

A patch can be found at 
http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level.patch
Please note that this patch will break the ini setting ABI. Thus all extensions registering ini settings will have to be recompiled.

[2008-01-13 03:14 UTC] root at net1 dot cc

I've been using the patched PHP for several hours now, and - confirmed - it's working flawless! This patch really fixes the issue! Thanks once again, Manuel!

For FreeBSD users, I've uploaded a modified patch file for deployment with the ports system, for ease of use, and instructions here:
http://mirror.net1.cc/projects/php-bug43677-patch/

[2008-01-17 13:40 UTC] manuel at mausz dot at

Err... php as apache module... :)

[2008-01-17 16:52 UTC] d at tpyo dot net

Thanks Manuel.  Patch works perfectly.  But I agree, it is a fairly 
serious issue that undoubtedly affects a lot of users.

[2008-01-21 18:37 UTC] manuel at mausz dot at

As I said before, my patch breaks the ini settings abi resulting in segfaults if "old" extensions are loaded. Due to the fact that one of my customers is using a proprietary extension I have implemented an alternate, dirty but hopefully non-breaking patch.

The patch stores the original value 3 bits to the left of the new value. This method won't break any php or pecl extensions (all checked). Only ext/reflection needs to be recompiled.

http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level2.patch

[2008-02-14 12:06 UTC] it at inmolinkmls dot com

We have compiled the latest CVS snapshot (http://snaps.php.net/php5.2-latest.tar.gz) on Linux kernel 2.6.9-42.plus.c4 (Centos 4) as apache2 module with no luck. We have used just the most basic configuration (--with-apxs2=/wwwroot/bin/apxs).

We have been able to reproduce the bug with 2 virtualhost, one with php_value and another one with php_admin_value. As soon as we load the one with php_admin_value, the include_path of the first one starts to randomly fail.

We have a serious problem with this bug, since we are developing an application with Zend Framework (Did you realize how seriously this bug affects Zend Framework MVC (Zend/Loader.php / loadFile (#125))? It just doesn't work at all because of the bug).

Hope to see this bug solved soon.

[2008-02-26 12:22 UTC] manuel at mausz dot at

Yes. The bug only occurs if you're mixing php_admin_value and php_value with the same ini-setting.

[2008-03-07 20:21 UTC] oliver dot graetz at gmx dot de

In order to avoid getting my report marked as a duplicate of this one:

I have experienced a similar problem with PHP 5.2.5. I am using set_include_path() but the PHP ignores the call and uses the value defined in the main php.ini file.

[2008-03-13 16:01 UTC] iliaa@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.