php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #34680 open_basedir half-resolving of symlinks
Submitted: 2005-09-29 16:47 UTC Modified: 2007-08-20 13:34 UTC
Votes:6
Avg. Score:4.8 ± 0.4
Reproduced:5 of 5 (100.0%)
Same Version:2 (40.0%)
Same OS:4 (80.0%)
From: ajakum at inode dot at Assigned:
Status: Closed Package: Documentation problem
PHP Version: Irrelevant OS: *
Private report: No CVE-ID: None
 [2005-09-29 16:47 UTC] 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)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-02 13:04 UTC] sniper@php.net
See bug #30188 (last comment by tony2001)

 [2005-10-02 15:16 UTC] 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.
 [2006-03-19 22:08 UTC] 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
 [2007-08-20 13:34 UTC] vrana@php.net
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."
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 07:01:28 2024 UTC