#34680 [Com]: open_basedir half-resolving of symlinks

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] sniper@php.net 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