ID: 34680
Updated by: [EMAIL PROTECTED]
Reported By: ajakum at inode dot at
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: *
PHP Version: Irrelevant
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
"If the file doesn't exist then the symlink couldn't be resolved and
the filename is compared to (a resolved) open_basedir."
Previous Comments:
------------------------------------------------------------------------
[2006-03-19 22:08:51] mosner at feg dot de
I've got hit by the same issue, and it makes open_basedir essentially
useless since *there is no way* of creating files within symlinked
directories even if both the native and the symlinked version of the
directory are listed in open_basedir.
The treatment of this as a non-bug by PHP developers is not really
satisfactory.
I seriously consider "fixing" this bug in our local installation of PHP
since several TYPO3 users are affected.
Cheers,
Hans-Martin
------------------------------------------------------------------------
[2005-10-02 15:16:50] ajakum at inode dot at
I did read his comment (see my original report).
Why shouldn't it possible to resolve (directory-)symlinks for files
that are created in existing directories in this case? It really breaks
open_basedir with symlinks.
I would at least suggest a better documentation of this "feature";
regardless of me considering this to be a bug.
------------------------------------------------------------------------
[2005-10-02 13:04:02] [EMAIL PROTECTED]
See bug #30188 (last comment by tony2001)
------------------------------------------------------------------------
[2005-09-29 16:47:32] ajakum at inode dot at
Description:
------------
When open_basedir is set to /home/user, and /home/user is symlinked to
/home2/user, then actions like creating files containing the path
"/home/user" fail.
All symlinks within the open_basedir value are getting resolved to
their real locations, meaning that a setting of "/home/user:/home2/user"
gets resolved to "/home2/user:/home2/user" (as documented).
What users would expect is that symlinks are also resolved in the
destination filenames of file-manipulating actions. Currently this isn't
being done, leading to open_basedir restriction errors.
This behaviour has already been reported as #32851, #31309 and #30188,
mostly with a solution of providing a link to the latest CVS snapshots
or with no result. php4-STABLE-200509291243 and php5-STABLE-200509291239
both still have this problem.
If this a feature, it should be documented in another way, mentioning
that the symlink-resolving is only done on one side and that using
symlinks in open_basedir does not work for creating files without
providing the "real" (non-symlinked) filename/path. If it isn't, this is
most likely a bug and should be solved.
Reproduce code:
---------------
symlink /home/test -> /home2/test
open_basedir /home/test:/home2/test
<?php fopen("/home/test/foobar","w"); ?>
Expected result:
----------------
No errors? :)
Actual result:
--------------
Warning: fopen(): open_basedir restriction in effect.
File(/home/test/foobar) is not within the allowed path(s):
(/home/test:/home2/test)
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=34680&edit=1
