#44271 [Fbk->Opn]: open_basedir resolves links on link-specific operations

 ID:               44271
 User updated by:  tautolog at gmail dot com
 Reported By:      tautolog at gmail dot com
-Status:           Feedback
+Status:           Open
 Bug Type:         Safe Mode/open_basedir
 Operating System: DragonFly BSD
 PHP Version:      5.2.5
 Assigned To:      fb-req-jani
 New Comment:

Hi,

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.

Thanks,

Ben


Previous Comments:
------------------------------------------------------------------------

[2008-08-12 08:58:22] [email protected]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz

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-02-27 20:17:16] tautolog at gmail dot com

Description:
------------
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:
lchown()
lstat()
readlink()
rename()
rmdir()
unlink()
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:
----------------
1

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



------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=44271&edit=1