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:
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
Previous Comments:
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
[2002-10-31 17:09:40] [EMAIL PROTECTED]
I have tried to do workarounds earlier.
But it seems that this one here now has solved both issues,
the wrong random "basedir message" and the segfaults I encountered with
my first two patches.
http://people.freebsd.org/~mbr/patches/patch-main+fopen_wrappers.c
The solution is quite easy. In the onyl case where the error happens,
zend_get_executed_filename() is correct.
and can be used.
Since the error happens on perfect legitimate requests,
which work most of the time, I don't think this is a
security risk. If no executed filename is set, I set
$newpath to a empty string.
Note that this is a workaround only. And I print
the errors to syslog, since I can watch that easier.
------------------------------------------------------------------------
[2002-10-31 16:34:24] [EMAIL PROTECTED]
It looks to me that $path is composed somewhere.
And a the old basedir entry was not overwritten
correctly.
So $path is $basedir + $called phpfile and
the $basedir is plain wrong.
Some hint where this happens ?
------------------------------------------------------------------------
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
