ID: 43677 User updated by: root at net1 dot cc 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:
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/ Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2008-01-07 20:57:58] tborgans at gmx dot de same problem here on linux with 5.2.5, apache 1.3.39 ------------------------------------------------------------------------ [2008-01-06 21:38:14] 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? ------------------------------------------------------------------------ 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
