ID: 48744 User updated by: tom at ideaweb dot de Reported By: tom at ideaweb dot de Status: Open Bug Type: Safe Mode/open_basedir Operating System: Linux Debian Etch PHP Version: 5.3.0 Assigned To: fb-req-jani New Comment:
Maybe i'm wrong, if add the "prefix" path where php is installed to open_basedir directive, the segmentation fault and the strange "unicode" outputs are gone on all my machines (linux+osx) ./configure \ --prefix=/www/prog/php/5.3.0 \ php_admin_value open_basedir /www/htdocs/ecolint.ch/dev:/www/htdocs/ecolint.ch/tmp:/www/htdocs/ecol int.ch/mysql:/www/prog/php but... it should be confirmed by others! =) Previous Comments: ------------------------------------------------------------------------ [2009-07-31 15:54:07] tom at ideaweb dot de My problem is, currently its only the first linux server with running php53. Other server needs several modules like ionCube which seems to be not working with, maybe not compatible/supported by the vendor. But i tried it with one server... iconCube will be loaded, but php53 throws a lot of errors if open_basedir is enabled. I got errors that iconcube is not in allowed path. A module in "not allowed path"? For ex. i defined 3 entries for open_basedir like /var/www:/var/tmp:/var/upload and i get 3 errors that /var/www/iconcube.so, /var/tmp/iconcube.so etc. is not in allowed path. Thats why currently i cannot check the issue with the segmentation fault. Otherwise i "found" a simple server with a lot of wordpress blogs and i installed php53. With open_basedir enabled 70% of requests throw an HTTP 500 (not segmentation fault), but without open_basedir the server runs smoothly, realy strange... the same issue but "HTTP 500"?? Or is wordpress/apache/mod_rewrite the troublemaker? I have no idea, how i can debug it. I reversed the installation because the blogs has to run... Thats why i installed a new server in our office and installed one of our running project, with the same configuration and installing procedure like all our other servers (see first post). Without open_basedir enabled it runs but otherwise 20% of the request fails with the following error message: Warning: Unknown: open_basedir restriction in effect. File(/var/www/bebees/trunk/bebees/index.php) is not within the allowed path(s): (ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZMaṀ]) in Unknown on line 0 Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 Fatal error: Unknown: Failed opening required '/var/www/bebees/trunk/bebees/index.php' (include_path='.:/www/prog/php/5.3.0/lib/php') in Unknown on line 0 If i make an erroron purpose, php throws an message as expected for ex.: Warning: include_once() [function.include-once]: open_basedir restriction in effect. File(/var/www/ideacmf/tags/1_0_4/core/cmf.php) is not within the allowed path(s): (/www/tmp:/var/www/bebees/trunk) in /var/www/bebees/trunk/bebees/index.php on line 16 Than i installed the same project which is installed as in my first post, but same result, no segmentation fault: Warning: Unknown: open_basedir restriction in effect. File(/var/www/ecolint/trunk/admin/index.php) is not within the allowed path(s): (M۸) in Unknown on line 0 Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 Fatal error: Unknown: Failed opening required '/var/www/ecolint/trunk/admin/index.php' (include_path='.:/www/prog/php/5.3.0/lib/php') in Unknown on line 0 On the test server, which i've reported first, i have no clue what i can do else, because i've never learned/used c/c++ with all its dev tools or how i can provide more information to fixing this issue, maybe something with used adaptec driver in kernel, which returns an "unexpected result" which let apache runs in trouble, no idea... Sorry for the information leak =( ...) ------------------------------------------------------------------------ [2009-07-30 09:13:51] starcraftmazter at gmail dot com 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 ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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
