ID: 28947
User updated by: johnsteed99 at yahoo dot it
Reported By: johnsteed99 at yahoo dot it
-Status: Feedback
+Status: Open
Bug Type: *Directory/Filesystem functions
Operating System: Linux Red Hat 7.2.2
PHP Version: 4.3.7
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2004-06-28 14:40:41] johnsteed99 at yahoo dot it
In the code, $upl_dir misses last slash, so line 4 should be
$upl_dir = '/WWW/mysite/upl/';
------------------------------------------------------------------------
[2004-06-28 12:51:54] johnsteed99 at yahoo dot it
Description:
------------
We have a symbolic link to apache's htdocs:
/WWW -> /usr/local/apache2/htdocs
We are not in safe mode, but we set open_basedir. If we try to use a
function that has to create a file (move_uploaded_file, tempnam, fopen
in W mode, copy, etc.) and we specify a path using the symbolic link
(/WWW/mysite/upl), php does not allow us to proceed, alerting that
open_basedir restriction is in effect. If the file is present so it has
only to be opened, everything is fine. If we specify the real path
(/usr/local/apache2/htdocs/mysite/upl), it works both in creation and
opening. No problems found when opening files in read mode.
Specifying open_basedir as link or real path does not affect the
problem. We think the bug should be in fopen_wrappers.c, function
expand_filepath().
Reproduce code:
---------------
<?
if ($_POST["action"] == 'save')
{
$upl_dir = '/WWW/mysite/upl';
$upl_file = $upl_dir.$_FILES['userfile']['name'];
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>
Expected result:
----------------
Resolved destination directory is in open_basedir, so it should be
allowed to create a file.
Actual result:
--------------
When affected file is not existent, php does not allow to create it if
a directory in its path is specified using a symbolic link.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=28947&edit=1
