ID: 20190 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: FreeBSD PHP Version: 4.3.0-dev New Comment:
Hi, >when this bug occurs, to confirm the wrong ini values? Ok, i'll do that. >1) there are 2 vhosts, where vhost A has open_basedir >restriction in effect, via php_admin_value in ><VirtualHost> context and vhost B >doesn't Nope. Both virtal servers have a open basedir restriction turned on here. >2) vhost B includes a file and subsequently vhost A >includes one. That's correct. For some strange reason, the bug does not happen on a test setup with the same apache config. Of course I was not able to copy all web-stuff over and simulate true load. So it is very difficult to reproduce. Martin Previous Comments: ------------------------------------------------------------------------ [2002-11-14 11:39:16] [EMAIL PROTECTED] Could you test the values: registered_zend_ini_directives and EG(ini_directives) when this bug occurs, to confirm the wrong ini values? I'm trying to reproduce this, can you confirm, that this bug happens when: 1) there are 2 vhosts, where vhost A has open_basedir restriction in effect, via php_admin_value in <VirtualHost> context and vhost B doesn't 2) vhost B includes a file and subsequently vhost A includes one. So in order to increase the chances of hitting this bug, one could: set Max and MinSpareServers to 1 and request the different vhosts? ------------------------------------------------------------------------ [2002-11-14 03:09:27] [EMAIL PROTECTED] I can confirm that it still happens with the latest cvs 4.3 snapshot from yesterday (2002-11-13). If I get some pointers, I could add some debug code. Funny thing is that the webserver runs about 30min to 2 hours ok, and then I hit begin to hit the bug. Always after the same files: It's always the same, you can see it because the filename has two slashes /www/doc/customer2/html/visions/php// This path really exists. The thing that does not exist, is the file wrapper.php. It exists in the customer1 path so we really really should not end here. Nov 14 05:37:24 server-bsl1 httpd: open_basedir: Used openbasedir /www/doc/custermer1, file /www/doc/customer2/html/visions/php//wrapper.php executed_filename (/www/doc/customer1/index.php) It looks to me that this case only happens after the apache child has processed a include as last thing and then preceeds again a different webserver. Anyone knows more ? Martin ------------------------------------------------------------------------ [2002-11-02 14:27:04] [EMAIL PROTECTED] I'd like to jump this upto a critical standing. Mainly because it will get someone else to review the patch. Hopefully that someone else will be a bit more intimately knowledgable with the whole Zend memory system than I. ------------------------------------------------------------------------ [2002-11-01 08:22:04] [EMAIL PROTECTED] My patch explained a bit more ... The main trick is that we do a stat() on $path: if (( stat (path, &statbuf)) < 0) { If the file does not exist, we can be sure that we triggered the bug and we let the check pass. As already said, this is only a workaround for the ugly bug ... Martin ------------------------------------------------------------------------ [2002-10-31 18:06:01] [EMAIL PROTECTED] hi all, I think I can now even provide more information ... :-) $path beeing wrong does relate from a wrong include_path. It looks like if the apache child has proceeded a request from a webserver with include_path or safe_mode_include_dir set, these are still there. If now a virtual server without these admin values is called, we fail. Looks to me like these variables are not properly initialized and still contain their old values. Of course the openbasedir checks then against the wrong include path and there we are :-( I'll look if I can really find the bug and fix it. Martin ------------------------------------------------------------------------ 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/20190 -- Edit this bug report at http://bugs.php.net/?id=20190&edit=1