Note that this bug is similar to a other bug,

http://bugs.php.net/bug.php?id=19292

It's not the same bug. There were some checks wrong
in fopen_wrappers.c. This is fixed in cvs.

This bug does show similar results as 19292,
but the source of the problem is completly different.

This a webserver with ~400 virtual servers, ~100
have php enabled.

I see the bug happen if I access frequently
pages of customer 1 (php enabled) and at the same time
customer 2.

Previous dump was not the right one, sorry. I had
dumps for children disabled. This is now the right one ...

(gdb) bt
#0  0x280de8e1 in strlen () from /usr/lib/libc.so.4
#1  0x17 in ?? ()
#2  0x2836decb in php_check_open_basedir (path=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php")
    at fopen_wrappers.c:211
#3  0x2836e19f in php_fopen_and_set_opened_path (
    path=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php", mode=0x284e1ac3 "rb",
    opened_path=0xbfbff8d8) at fopen_wrappers.c:309
#4  0x2836e89d in php_fopen_with_path (filename=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php",
    mode=0x284e1ac3 "rb", path=0x81ebb50 ".", opened_path=0xbfbff8d8) at fopen_wrappers.c:494
#5  0x2836edc0 in php_fopen_url_wrapper (path=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php",
    mode=0x284e1ac3 "rb", options=1, issock=0xbfbfe6f0, socketd=0xbfbfe6ec, opened_path=0xbfbff8d8)
    at fopen_wrappers.c:612
#6  0x2836e26d in php_fopen_wrapper (path=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php",
    mode=0x284e1ac3 "rb", options=1, issock=0xbfbfe6f0, socketd=0xbfbfe6ec, opened_path=0xbfbff8d8)
    at fopen_wrappers.c:335
#7  0x2836b38c in php_fopen_wrapper_for_zend (
    filename=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php", opened_path=0xbfbff8d8) at main.c:583
#8  0x28336463 in open_file_for_scanning (file_handle=0xbfbff8d0) at zend_language_scanner.c:2952
#9  0x28336611 in compile_file (file_handle=0xbfbff8d0, type=2) at zend_language_scanner.c:3009
#10 0x2835bb4f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:823
#11 0x2836d0b9 in php_execute_script (primary_file=0xbfbff8d0) at main.c:1399
#12 0x28367d82 in apache_php_module_main (r=0x8c78038, display_source_mode=0) at sapi_apache.c:98
#13 0x28368c2c in send_php (r=0x8c78038, display_source_mode=0,
    filename=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php") at mod_php4.c:684
#14 0x28368c9f in send_parsed_php (r=0x8c78038) at mod_php4.c:703

(gdb) list
206                     char *newpath;
207                     char *ptr;
208                     char *end;
209
210                     pathbuf = estrdup(PG(open_basedir));
211                     newpath = estrdup(zend_get_executed_filename(TSRMLS_C));
212
213                     ptr = pathbuf;
214                     while (ptr && *ptr) {
215                             end = strchr(ptr, DEFAULT_DIR_SEPARATOR);

If you try a snapshot, put the version correctly here.
Also, you added comment to http://bugs.php.net/bug.php?id=19292 that it should be critical, and now you say it's fixed. So what's the real thing here?

Hi,

>should be critical, and now you say it's fixed.
>So what's the real thing here?

It seems that we hit two different bugs. I've seen
that bug 19292 was fixed for the part when a safe_mode
include dir was involved. 

But here the problem is more complex. Some global php
variables seem to be corrupted, or not properly initialised.

I'm still in gdb and try to find out why.

Martin

Ok, I think I'm a bit smarter now.

zend_get_executed_filename() can only be used if
zend_is_executing(TSRMLS_C) is true. That explains
the uninitialisized values there.

If I do a check for this, the errors go away and the
segfaults are gone.

Buth $path can still point to a wrong virtual server.
That happens in 1/500 requests, and the thing is random.

I try to solve this now.
Martin

This is a example:

Correct:

PG(open_basedir)=/www/doc/www.aaa.ch-80, 

Correct:

zend_get_executed_filename() = /www/doc/www.aaa.ch-80/index.php, 

Wrong:

path=/www/doc/www.bbb.imp.ch-80/html/visions/php//ueberuns/mannschaft.php

There is no "/www/doc/www.bbb.imp.ch-80/html/visions/php"
exists, but this is a different customer.

The correct filename would be: "/www/doc/www.aaa.ch-80/ueberuns/mannschaft.php"

Also note the two "//" slashes ...

Sorry ...

>There is no "/www/doc/www.bbb.imp.ch-80/html/visions/php"
>exists, but this is a different customer.
This should be:

There is a dir "/www/doc/www.bbb.imp.ch-80 ..."
but this is a different customer.

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 ?

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.

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

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

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. 

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

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?

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

I upgraded to 4.3 the other day and ran into this problem big time. Today I went back to 4.2.3 and am still running into the error(s) occasionally... I've made sure that PHP 4.2.3 is installed and running and (according to phpinfo()) it is.

Apache 1.3.27 FreeeBSD 4.7p-1 PHP 4.2.3 and PHP 4.3.0 

Ack!

Have this problem on 4.3.0 RELEASE! and 4.2.3

upgrade Version on this bug please.

*sigh*

STILL happening with 4.3.1 FreeBSD 4.7 - 5.0

Reading the NEWS file or the announcement for 4.3.1
would have told that 4.3.1 does not have ANY other fixes
but the fix for the CGI bug.

Please try the latest STABLE snapshot from http://snaps.php.net/ which has a lot of fixes..

[mbr at freebsd dot org]

Lot of fixes to quite a many parts have been committed
since your last update. Could you let us know if the latest
snapshot is any better now? (getting desperate here.. :I)

Hi,

I can confirm that it still happens. After running 32
hours, the bug appeared again a 4-Stable snapshot from
11.4.2003.

Should I make the thing write a core so we see what
really happened before ?

:-(

Yes, a backtrace might help a bit more than just saying 'this is still happening'. :)

Still waiting for that backtrace, preferrably generated
with latest stable CVS snapshot, of course.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.