|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #44271 open_basedir resolves links on link-specific operations
Submitted: 2008-02-27 20:17 UTC Modified: 2008-08-21 01:00 UTC
Avg. Score:3.8 ± 0.8
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:0 (0.0%)
From: tautolog at gmail dot com Assigned: fb-req-jani (profile)
Status: No Feedback Package: Safe Mode/open_basedir
PHP Version: 5.2.5 OS: DragonFly BSD
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
10 + 29 = ?
Subscribe to this entry?

 [2008-02-27 20:17 UTC] tautolog at gmail dot com
This is not a security issue. It is just a functionality issue.

open_basedir resolves links on link-specific operations, getting in the way of expected behavior.

I don't think that the ability to read a link target (the target itself, not the file the target resolves to) within the basedir is a security concern because it is no different than the ability to read a config file which refers to a file outside of the basedir.

In my thinking about this issue, I am viewing a symbolic link as just an alternate way to associate data with a file that just happens to have common support for treating the data as a target.

See my reproduce code. Clearly, "/tmp/testlink" is in the allowed path of "home/ben/public_html:/tmp", but since it resolves to "/test", it is not being allowed.

The following system calls (and therefore PHP functions) do not follow symlinks, according to symlink(7) on my BSD system:
remove() (just an alias to unlink which is not in PHP)

I tested all of them. All of them have this issue.

rmdir() is an odd one. According to the manual, if you use it on a symbolic link, it should return ENOTDIR. 

$ mkdir /tmp/link_target
$ ln -s /tmp/link_target /tmp/testlink
$ rmdir /tmp/testlink
rmdir: /tmp/testlink: Not a directory

I have been using symbolic links to back a fast, simple, global, atomic, persistent hash, where the link filename is the key and the link value is the value. I have been running the application with open_basedir set to try to find compatibility problems with it, and found this issue. To work around it, I prefix all values with "./" now.

However, there are other cases that cannot be worked around. For example, a php file manager would not even be able to tell whether the file were a link, let alone read its value or delete it.

I have some interest in working on a patch. If you agree that it is desirable for open_basedir to not resolve links in some cases, I may be able to provide a patch.

Just in case, I also tested the case where a link is outside open_basedir, but it resolves within open_basedir, and it blocked that, which I agree should be the expected behavior.

Reproduce code:
Add /tmp to open_basedir

$ ln -s /test /tmp/testlink

<?php echo is_link("/tmp/testlink") ; ?>

Expected result:

Actual result:
Warning: is_link(): open_basedir restriction in effect. File(/tmp/testlink) is not within the allowed path(s): (/home/ben/public_html:/tmp) in /home/ben/public_html/cvs/app-modernbill-admin/include/lib-action/migrate/- on line 1


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-08-12 08:58 UTC]
Please try using this CVS snapshot:

There are some fixes done in PHP_5_3 which most likely fix this problem. Note: Those fixes will NOT be backported to 5.2 branch!
 [2008-08-12 18:05 UTC] tautolog at gmail dot com

Thank you for your time and attention on this issue.

I tested all of the functions at issue using the snapshot build php5.3-200808121630.

I get the same result as before: the same warning, and it returns failure.

Should I try again at a later date?

Would you like me to take a shot at fixing it? I recognize that it is in a fairly sensitive area of the code, and you might rather just do it yourself, or not bother with changes there.

I am not bothered about backporting. The workaround for my case was simple enough, and I am now at a different job that doesn't involve PHP.


 [2008-08-13 19:05 UTC]
Patches are always welcome.
 [2008-08-21 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".
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Sat Dec 02 00:01:27 2023 UTC