|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2004-06-28 12:51 UTC] 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.
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Tue Oct 28 11:00:01 2025 UTC |
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.