Note: For shared webhosting, we recommend chroot + apache2 + php-fastcgi + suexec as a fast, secure environment. open_basedir is just one component that can improve considerably security.
PHP open_basedir is a good means to improve security in a shared webhosting environment (or if you host multiple G2 installations for multiple users). With open_basedir, account owner X will no longer be able to access files of account owner Y. Without open_basedir (or other similar security precautions), user X can read the config.php file of user Y, user X can delete the albums of user Y etc. (of course this doesn't apply to a properly configured chroot + php-fastcgi + suexec webserver).
From http://www.php.net/manual/en/security.apache.php:
There is a better solution than starting every virtual host in a seperate instance, which is wasting ressources. You can set open_basedir dynamically for every virtual host you have, so every PHP script on a virtual host is jailed to its document root. Example: <VirtualHost www.example.com> ServerName www.example.com DocumentRoot /www-home/example.com [...] <Location /> php_admin_value open_basedir \ "/www-home/example.com/:/usr/lib/php/" </Location> </VirtualHost> If you set safe_mode on, then the script can only use binaries in given directories (make a special dir only with the binaries your customers may use). Now no user of a virtual host can read/write/modify the data of another user on your machine.
If you use open_basedir in conjunction with symlinks, then you'll encounter a problem with the current installation of G2. Summary of the open_basedir + symlink problem: There's a problem with [b]symbolic links[/b] and [b]open_basedir[/b]. If you're using one of the two, it works, but both at the same time will result in this problem. The explanation of the php dev at http://bugs.php.net/bug.php?id=30188 was correct:
document root is: "/home/wejn/x/docs/html/".
While "/home/wejn/x/docs/html/" is symlink to: "/home/wejn/x/docs1/html/".
I have safe_mode enabled and open_basedir set to "/home/wejn/x/docs/html:/home/wejn/x/docs1/html".
With this setup I'm unable to perform:
copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");
open_basedir is senseless, as it's similar to "/home/wejn/x/docs/html:/home/wejn/x/docs/html", because open_basedir's values are resolved too.
Obviously PHP cannot resolve "/home/wejn/x/docs1/html/y" as it even doesn't exist, so it compares non-existing "/home/wejn/x/docs1/html/y" to "/home/wejn/x/docs/html/" and reports that they aren't the same.
