ID: 34680
Comment by: mosner at feg dot de
Reported By: ajakum at inode dot at
Status: Open
Bug Type: Documentation problem
Operating System: *
PHP Version: Irrelevant
New Comment:
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
Previous Comments:
------------------------------------------------------------------------
[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
