|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #32851 open_basedir restrictions do not work with file creation in symlinked directory
Submitted: 2005-04-27 12:05 UTC Modified: 2005-07-12 01:00 UTC
Avg. Score:4.8 ± 0.4
Reproduced:9 of 9 (100.0%)
Same Version:5 (55.6%)
Same OS:5 (55.6%)
From: stegelmann at rz dot rwth-aachen dot de Assigned:
Status: No Feedback Package: Safe Mode/open_basedir
PHP Version: 5.0.4, 4.3.11 OS: SunOS 5.8
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2005-04-27 12:05 UTC] stegelmann at rz dot rwth-aachen dot de
We have some Apache/1.3.31 vhosts with open_basedir restrictions:

php_admin_value open_basedir "/export/home/websites/it/:/export2/home/websites/it/:/tmp/:/var/tmp/"

/export/home/websites/it/ is a symlink to the directory /export2/home/websites/it/ .

A script writing to an existing file in /export/home/websites/it/ works without a flaw.
Removing the file (so the script should create the file) produces an open_basedir warning.

(The creation of a file in the real directory /export2/home/websites/it/ works.)

I've already checked the (symlink-)ownership and directory-permissions. safe_mode is disabled for testing purposes.

Reproduce code:
  $f = fopen("/export/home/websites/it/test", "w");

Expected result:
As the file's path is in the allowed paths the file should be created (as it can be read when it exists).

Actual result:
Warning: fopen(): open_basedir restriction in effect. File(/export/home/websites/it/test) is not within the allowed path(s): (/export/home/websites/it:/export2/home/websites/it:/tmp/:/var/tmp/) in /export2/home/websites/it/test.php on line 2

Warning: fopen(/export/home/websites/it/test): failed to open stream: Not owner in /export2/home/websites/it/test.php on line 2


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-04-27 12:59 UTC]
Does this work:

$f = fopen("/export2/home/websites/it/test", "w");

ie. writing to the actual directory..?

 [2005-04-27 14:29 UTC] stegelmann at rz dot rwth-aachen dot de
$f = fopen("/export2/home/websites/it/test", "w");

does work.
 [2005-04-27 14:45 UTC] stegelmann at rz dot rwth-aachen dot de
To perhaps clarify - after the file was created with your code:

$f = fopen("/export2/home/websites/it/test", "w");

the previously unsuccessful attempt:

$f = fopen("/export/home/websites/it/test", "w");

does work (as I mentioned in the initial report).
So just the file's creation fails in combination with the symlink.
 [2005-04-27 23:28 UTC]
This is expected behaviour and it's documented in the docs:
"When a script tries to open a file with, for example, fopen() or gzopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to open it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink."
Pay attentions to the last sentence.
 [2005-04-28 00:06 UTC] stegelmann at rz dot rwth-aachen dot de
I've read the documentation. At the risk of repeating myself:

If the symlink was resolved - I would expect at least one of the given open_basedirs to match (as both possibilities are specified - resolved and unresolved).

If this is not the intended way it should work, why is there a difference between creating a new and opening an existing file (as opening an existing file in the symlinked directory works, while creating a new file fails)?
 [2005-07-04 01:05 UTC]
Please try using this CVS snapshot:
For Windows:

 [2005-07-12 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2005-09-29 16:25 UTC] ajakum at inode dot at
I suppose the problem lies with the fact that symlinks in open_basedir are getting resolved, while symlinks in fopen-calls aren't.
For example, we have open_basedir /home/bla:/home2/bla and symlink /home/bla -> /home2/bla.
The following fopen calls fails:
since the open_basedir virtually gets resolved to /home2/bla:/home2/bla (as documented in the php docs). What is not documented and I still think is a bug (even after reading #32851, #31309 and some not very friendly comment by tony2001 in #30188) is the fact that the symlink within the directory of the destination path is not getting resolved.
One can not use any path within "/home/bla" for file creating (or upload moving) as the open_basedir values have their symlinks resolved while the destination files haven't.
We solved it by symlinking a subdirectory of /home/bla to /home2/bla and using that one, as this solution doesn't use a symlinked path in the open_basedir setting which would get resolved.
I still think it should be possible to set an open_basedir restriction to a symlink without running into the above-mentioned problem, e.g. by also resolving the symlink in the destination filenames.
This has been verified with php4-STABLE-200509291243 and by looking at the source of php5-STABLE-200509291239.
 [2008-11-17 17:27 UTC] webworkings at gmail dot com
I was very impressed about opportunity to work from home and I register to website now i have  lots of  offers to work from home..  I am very thankful my friend who told me about this website. I quit my job and I am working  from home only. I am very happy  being of my family together all the time ;) Did you hear something about that? Maybe You know something about that too?
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 20 01:01:28 2024 UTC