ID: 28947
Updated by: [EMAIL PROTECTED]
Reported By: johnsteed99 at yahoo dot it
-Status: Open
+Status: Bogus
Bug Type: *Directory/Filesystem functions
Operating System: Linux Red Hat 7.2.2
PHP Version: 4.3.7
New Comment:
All symbolic links are resolved, so you need to add real path to
open_basedir instead of link path.
Previous Comments:
------------------------------------------------------------------------
[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] [EMAIL PROTECTED]
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)
------------------------------------------------------------------------
[2004-06-28 22:06:20] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The open_basedir is applied on the resolved name, which
prevents the use of symlinks to create open_basedir
bypasses. This is intended & expected behavior.
------------------------------------------------------------------------
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
