ID: 48744
Comment by: rs at qcm dot cz
Reported By: tom at ideaweb dot de
Status: Feedback
Bug Type: Safe Mode/open_basedir
Operating System: Linux Debian Etch
PHP Version: 5.3.0
Assigned To: fb-req-jani
New Comment:
Ok, I think I've ran into some kind of overflow game here. This is my
test PHP setup in httpd.conf:
php_admin_value safe_mode 0
php_admin_value upload_tmp_dir somepath1_123456
php_admin_value session.save_path somepath2_123456
php_admin_value open_basedir /home/webs/
php_admin_value include_path
.:/usr/share/misc:/usr/share:/home/webs/.libs:/home/webs/.libs/php-pear
php_admin_value display_errors On
To be able to see what path is being looked for in open_basedir I'm
including a file that is not within the /home/webs directory.
This is the result as expected:
Warning: include_once(): open_basedir restriction in effect.
File(/tmp/something) is not within the allowed path(s): (/home/webs/) in
/home/webs/_devel/public/index2.php on line 13 Call Stack: 0.0000 616224
1. {main}()
Note that the upload_tmp_dir and session.save_path variables are
exactly 16 chars long. Now let's shorten the second one a little bit:
php_admin_value upload_tmp_dir somepath1_123456
php_admin_value session.save_path somepath2_12345
php_admin_value open_basedir /home/webs/
And what I got here:
Warning: include_once(): open_basedir restriction in effect.
File(/tmp/something) is not within the allowed path(s):
(somepath2_12345) in /home/webs/_devel/public/index2.php on line 13 Call
Stack: 0.0000 616184 1. {main}()
Oops? Is that path really what I have set? Let's shorten the next one:
php_admin_value upload_tmp_dir somepath1_12345
php_admin_value session.save_path somepath2_12345
php_admin_value open_basedir /home/webs/
And here we go:
Warning: include_once(): open_basedir restriction in effect.
File(/tmp/something) is not within the allowed path(s):
(somepath1_12345) in /home/webs/_devel/public/index2.php on line 13 Call
Stack: 0.0000 616176 1. {main}()
Looks like for three different setups there different strings slip into
the open_basedir variable. Silly.
I hope this helps a bit in finding the bug.
Previous Comments:
------------------------------------------------------------------------
[2009-07-17 10:19:30] rs at qcm dot cz
Hello everyone!
I'm experiencing similar problems using PHP 5.3.0 final on 64-bit
CentOS with Apache 2.2.3.
I'm not actually getting segfaults but defining "php_admin_value
open_basedir /home/webs/" anywhere in httpd.conf results in open_basedir
errors that look like these:
Warning: Unknown: open_basedir restriction in effect.
File(/home/webs/_devel/public/index2.php) is not within the allowed
path(s): (0óûÇË*) in Unknown on line 0 Warning: Unknown: failed to
open stream: Operation not permitted in Unknown on line 0
The open_basedir variable value is distorted in a weird way and the
string remains the same until Apache is reloaded. Then it changes to a
different set of random characters.
>From what I've tried disabling all PHP extensions didn't make any
difference, the only thing that helps is defining open_basedir in
php.ini instead.
I'm running Apache in prefork mode and PHP with Thread Safety disabled.
------------------------------------------------------------------------
[2009-07-17 04:05:57] dougcsd at yahoo dot com
Here is more info on this.
I ran into this earlier while running 5.3 Alpha snapshots.
The Snapshot: php5.3-200810090430 (Alpha 3) did not seem to have this
problem yet, and works ok. I have reproduced the problem on two
machines and multiple operating systems. I see the scrambled open
basedir paths in the apache logs when a simple phpinfo() fails.
Both systems were running Slackware 12.1 (one 32 bit, and one 64 bit)
BlueWhite64 for the 12.1 64 bit.
I recently upgraded to Slackware 12.2 on the 32 bit machine to upgrade
the libc to a newer version and see if it helped, but the problem
persists.
I first saw this problem in php5.3-200903230730, and assumed it was a
development bug that would work itself out in time, and simply reverted
back. However the problem has carried over to 5.3.0 release.
I have done a bit of digging and it appears that both PHP and Apache
are using pthreads on these machines. Because of the randomness of when
the corruption occurs, I believe this may be related to a threading
issue, but I have yet to discover any additional details.
------------------------------------------------------------------------
[2009-07-16 13:08:25] j...@php.net
Have you figured out the differences between the working and
non-working servers running 5.3 yet? That's propably the only way to
debug this. Otherwise, just let this rot.
------------------------------------------------------------------------
[2009-07-15 07:29:24] tom at ideaweb dot de
Sorry for the delay, the test server was in use...
Seems to be the same =(
(gdb) run -X -d /www/apache/current/
Starting program: /www/apache/2.2.11/bin/httpd -X -d
/www/apache/current/
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1212967232 (LWP 27684)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212967232 (LWP 27684)]
0xb755848f in OnUpdateBaseDir (entry=0x824fbb8,
new_value=0x83b5070
"/www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/eco
lint.ch/mysql",
new_value_length=82, mh_arg1=0x48, mh_arg2=0xb7b37e80,
mh_arg3=0x0, stage=4)
at /www/src/php5.3-200907101630/main/fopen_wrappers.c:103
103 if (!*p || !**p) {
(gdb)
------------------------------------------------------------------------
[2009-07-10 22:15:18] j...@php.net
Is the backtrace the same?
------------------------------------------------------------------------
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/48744
--
Edit this bug report at http://bugs.php.net/?id=48744&edit=1
