ID: 48744 Comment by: starcraftmazter at gmail dot com Reported By: tom at ideaweb dot de Status: No Feedback Bug Type: Safe Mode/open_basedir Operating System: Linux Debian Etch PHP Version: 5.3.0 Assigned To: fb-req-jani New Comment:
Hello there I can confirm that I have a very similar issue. I have been running PHP with open_basedir for quite some time. I upgraded to php 5.3.0 recently, previously having ran php 5.2.5. Immediately after installing the newly compiled version, the issues began. The problem as I experience it, is that the "open_basedir" setting seems to be composed of random, non latin1 characters (displayed as symbols by the browser). I cannot draw any reasons as to which users are affected by this or why, but it does not happen to everyone - it is seemingly random. I am using CentOS 5.3 with the latest cPanel 11 on CURRENT which manages the open_basedir. I am using Apache 2.2.6. My compile string is as follows; './configure' '--prefix=/usr/local' '--with-apxs2=/usr/local/apache/bin/apxs' '--enable-bcmath' '--enable-calendar' '--enable-exif' '--enable-ftp' '--enable-gd-native-ttf' '--enable-libxml' '--enable-mbstring' '--enable-soap' '--enable-sockets' '--enable-zip' '--with-bz2' '--with-curl=/opt/curlssl/' '--with-curlwrappers' '--with-freetype-dir=/usr' '--with-gd' '--with-gettext' '--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/usr' '--with-jpeg-dir=/usr' '--with-kerberos' '--with-libdir=lib64' '--with-libxml-dir=/opt/xml2' '--with-libxml-dir=/opt/xml2/' '--with-mcrypt=/opt/libmcrypt/' '--with-mhash=/opt/mhash/' '--with-openssl-dir=/usr' '--with-pic' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-xsl=/opt/xslt/' '--with-zlib' '--with-zlib-dir=/usr' '--with-openssl=/usr' '--with-mysql' '--with-mysqli' '--with-pgsql' '--with-sqlite=shared' '--enable-pdo=shared' '--with-pdo-sqlite=shared' '--with-pdo-mysql=shared' '--with-pdo-pgsql=shared' '--with-magickwand=/usr/local/bin' You can check other relevant settings here: http://liway.com/test.php For reference, here is the screenshot of the exact error message which one of the accounts is getting, which shows the open_basedir setting being composed of weird characters. http://img75.imageshack.us/img75/6261/screenshot1a.png The situation involves phpbb3 trying to include parts of itself, so I am confident that it should be allowed, as it's in the same directory or close directories within a single account home folder. The second screenshot is of the relevant open_basedir setting in the httpd.conf file. I have checked the settings against those in the virtual hosts of other accounts where open_basedir works without errors, and I can confirm that they are absolutely identical (apart from the actual home directory). http://img75.imageshack.us/img75/626/screenshot2w.png Needless to say, this is a very serious issue, as open_basedir is an extremely important security measure for those of us who don't run suPHP, and now it is impossible to use it because of these problems. I'm available daily for testing, hope this bug report will get some new attention for developers. Cheers Previous Comments: ------------------------------------------------------------------------ [2009-07-24 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". ------------------------------------------------------------------------ [2009-07-19 17:24:31] vytas dot LT at gmail dot com I've noticed that one virtual host with open_basedir is working normally. Problem starts, when you using two or more virtual hosts in apache. Seems to be some sort of memory allocation problem. I have same issue on FreeBSD 7.2-p2 x64 jailed environment. Apache - 2.2.11 from latest FreeBSD ports (2.2.11_7). Error log shows something like: "PHP Warning: Unknown: open_basedir restriction in effect. File(/usr/local/www/apache22/data/info.php) is not within the allowed path(s): (\b) in Unknown on line 0" As you see - \b is the allowed paths, and my apache config file contains "php_admin_value open_basedir /usr/local/www/phpMyAdmin:/usr/local/www/apache22/data:/tmp:/manualbuilds/php53/lib/php". ------------------------------------------------------------------------ [2009-07-17 11:37:14] rs at qcm dot cz 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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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
