#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: *Directory/Filesystem functions
Operating System: Linux Red Hat 7.2.2
PHP Version: 4.3.7
New Comment:
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)
Previous Comments:
------------------------------------------------------------------------
[2004-06-28 22:06:20] iliaa@php.net
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
Thread (9 messages)