#28947 [Bgs->Opn]: open_basedir misfunction with symbolic links

ID: 28947 User updated by: johnsteed99 at yahoo dot it Reported By: johnsteed99 at yahoo dot it -Status: Bogus +Status: Open Bug Type: Safe Mode/open_basedir Operating System: Linux Red Hat 7.2.2 PHP Version: 4.3.7 New Comment: One year and a half later, I decided to re-open the bug. I had several mail from people complaining to have the same problem I reported, asking me direction to solve it. Unfortunately, I have no solution. So once again I am here asking to have a look at this bug, that is not bogus. Please spend 5 minutes to check it, as you can see it has a 100% rate of reproduction. Previous Comments: ------------------------------------------------------------------------ [2004-11-10 18:04:00] tony2001@php.net All symbolic links are resolved, so you need to add real path to open_basedir instead of link path. ------------------------------------------------------------------------ [2004-11-10 17:35:43] martijn at sipo dot nl I run into this exact problem with PHP 4.3.9 on Debian Woody. Opening an existing file for reading or writing works as expected; creating a new file or a directory fails with a warning about an open_basedir restriction. The resolved path of the file I try to create, is in open_basedir. ------------------------------------------------------------------------ [2004-06-30 13:19:14] johnsteed99 at yahoo dot it Apache has its document root in /usr/local/apache2/htdocs, and there is a symbolic link pointing to this directory (/WWW -> /usr/local/apache2/htdocs). Test site has this virtual host configuration in httpd.conf: <VirtualHost xxx.xxx.xxx.xxx:80> ServerName test.mysite.com DocumentRoot /WWW/mysite php_admin_value open_basedir "/WWW/mysite" </VirtualHost> In the file system, we have: /usr/local/apache2/htdocs/mysite/test, a directory with 777 permissions /usr/local/apache2/htdocs/mysite/testupload.php, a script with the following code: <? if ($_GET["action"] == 'save') { $upl_dir = '/WWW/mysite/test/'; // $upl_dir = '/usr/local/apache2/htdocs/mysite/test/'; $upl_file = $upl_dir.$_FILES['userfile']['name']; echo "src file: ".$_FILES['userfile']['tmp_name'].", dst file: $upl_file<br>"; if (! move_uploaded_file( $_FILES['userfile']['tmp_name'], $upl_file)) echo "failed<br>"; } ?> <html> <body bgcolor="#FFFFFF"> <form method="post" action="<? echo $PHP_SELF; ?>?action=save" enctype="multipart/form-data"> Send a file: <input type="file" name="userfile" /> <input type="submit" name="Submit" value="Send" /> </form> </body> </html> You can switch between the two $upl_dir to test the behaviour with symbolic link [S] and resolved name [R]. As previously stated, you should get this schema (we avoid to specify the way open_basedir is specified, since using [S] or [R] does not seem to affect the problem): path S S R R file exists Y N Y N restriction N Y N N Testing the problem on a different server, we found another strange behaviour with Apache/1.3.29 on Red Hat Linux 7.2 2.96-112.7.1 (php 4.3.7). Using the same configuration as before (just substituting the string 'apache2' with 'apache'), we get this schema: path S S R R file exists Y N Y N restriction Y* Y N N When the destination file is already existent, restriction applies but the existing file is deleted anyway. In both cases, we should expect no restriction using the symbolic link in the destination file path, having specified the symbolic link (or its the resolved name) in the open_basedir setting. We think that path's symbolic link is correctly resolved to prevent open_basedir bypasses, but then it should be tested with the resolved open_basedir settings to set the restriction. ------------------------------------------------------------------------ [2004-06-29 17:47:11] iliaa@php.net Please provide the necessary directory/file structure and a simple script that can be used to duplicate the behavior. ------------------------------------------------------------------------ [2004-06-29 10:46:13] johnsteed99 at yahoo dot it The point is that the resolved name of the path (/usr/local/apache2/htdocs/mysite) is present in open_basedir, and it makes no difference whether open_basedir is written as /WWW/mysite (symb. link) or /usr/local/apache2/htdocs/mysite (resolved name) - but it makes difference writing the path as symbolic link or resolved name. Then, since it gives no open_basedir restriction when the file is already present even if path is written as symbolic link, we think that this is actually a bug. This is a schema of php behaviour, where you can find the only two cases where restriction applies: open_basedir S S R R S S R R path S S S S R R R R file exists Y N Y N Y N Y N restriction N Y N Y N N N N (S:written as symb. link, R: written as resolved name) ------------------------------------------------------------------------ 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/28947 -- Edit this bug report at http://bugs.php.net/?id=28947&edit=1