php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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: No CVE-ID:
 [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

Add a Patch

Pull Requests

Add a Pull Request

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:35 UTC] manuel at mausz dot at
Can some dev please take a look at this (or the patch)?
This is a serious issue for all users running apache as module and mixing php_admin_value and php_value.

It also looks like this is the same as:
http://bugs.php.net/bug.php?id=43842
http://bugs.php.net/bug.php?id=43755
http://bugs.php.net/bug.php?id=43207
 [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-07 00:45 UTC] jani@php.net
See also bug #43755

 [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-21 12:56 UTC] tallyce at gmail dot com
See also bug
http://bugs.php.net/bug.php?id=44178
which I now see describes the same behaviour.
 [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.


 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Thu Apr 24 21:01:55 2014 UTC