ID: 43677 Comment by: manuel at mausz dot at Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment:
Err... php as apache module... :) Previous Comments: ------------------------------------------------------------------------ [2008-01-17 13:35:48] 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-13 03:14:53] 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-12 21:19:29] root at net1 dot cc I'm gonna test Manuel's patch (thanks!) and report back later if it does fix the problems observed. ------------------------------------------------------------------------ [2008-01-12 18:08:43] 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-07 22:57:03] 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. ------------------------------------------------------------------------ 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 http://bugs.php.net/43677 -- Edit this bug report at http://bugs.php.net/?id=43677&edit=1