#34680 [Opn->Csd]: open_basedir half-resolving of symlinks

ID: 34680 Updated by: vrana@php.net 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] 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