php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #30188 open_basedir check is badly performed under some circumstances
Submitted: 2004-09-21 23:50 UTC Modified: 2005-01-31 23:24 UTC
Votes:7
Avg. Score:4.7 ± 0.5
Reproduced:7 of 7 (100.0%)
Same Version:5 (71.4%)
Same OS:4 (57.1%)
From: lists+php at box dot cz Assigned:
Status: Not a bug Package: Safe Mode/open_basedir
PHP Version: 5.0.1 OS: Linux (Gentoo, latest)
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 !
Your email address:
MUST BE VALID
Solve the problem:
21 + 29 = ?
Subscribe to this entry?

 
 [2004-09-21 23:50 UTC] lists+php at box dot cz
Description:
------------
My setup:
document root is: "/home/wejn/x/docs/html/".

While "/home/wejn/x/docs/html/" is symlink to: "/home/wejn/x/docs1/html/".

I have safe_mode enabled and open_basedir set to "/home/wejn/x/docs/html:/home/wejn/x/docs1/html".

With this setup I'm unable to perform:

copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");

when "y" doesn't exist. If I touch "y" prior running the
script, everything runs just fine.

IMO, there is problem with symlink resolving code somewhere under 
php_check_specific_open_basedir().

It seems to me that more precise location of the bug is somewhere in virtual_file_ex() regarding the realpath() call.

Maybe it would be better to perform open_basedir check just on dirs instead of files (in various filesystem functions)?

Btw, this problem exists also in 4.3.8, which makes me think that it's there for a LONG time ... unnoticed.

W.

Reproduce code:
---------------
// when all conditions described above are met, this fails:
copy('/home/wejn/x/docs/html/x', '/home/wejn/x/docs/html/y');

Expected result:
----------------
no error.

Actual result:
--------------
Warning: copy() [function.copy]: open_basedir restriction in effect. File(/home/wejn/x/docs/html/y) is not within the allowed path(s): (/home/wejn/x/docs/html:/home/wejn/x/docs1/html) in /home/wejn/x/docs1/html/index.html on line 2

Warning: copy(/home/wejn/x/docs/html/y) [function.copy]: failed to open stream: Operation not permitted in /home/wejn/x/docs1/html/index.html on line 2

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-10-14 11:51 UTC] evp at heise dot de
> Maybe it would be better to perform open_basedir check just 
> on dirs
> instead of files (in various filesystem functions)?

No, because it's sometimes vital to have files in open_basedir to allow acces to one specific file without the need to put it  into a directory for its own.
 [2004-10-14 12:10 UTC] lists+php at box dot cz
> > Maybe it would be better to perform open_basedir check
> > just on dirs
> > instead of files (in various filesystem functions)?

> No, because it's sometimes vital to have files in
> open_basedir to allow acces to one specific file without
> the need to put it  into a directory for its own.

OK ... but the rest still applies. The code is obviously broken. And sorry, folks @ php.net ... but if I would ever use PHP in production, I would expect bugs to be solved in timely fashion, not after 6 months of waiting as "open" (or even not solved at all).

It imho says all the "right" things about PHP - it's still toy, it has (almost) no support, nobody really cares about users' aches, ...

It's simply another hack-it-yourself-or-shut-up thingie ... but I'm probably crying on wrong shoulder here, anyway. :)
 [2004-11-28 15:16 UTC] tony2001@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

"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.<-"

http://www.php.net/manual/en/features.safe-mode.php#ini.open-basedir

You have to copy file to "/home/wejn/x/docs1/html/" instead of it's symlink if want open_basedir to work properly.
 [2004-11-28 16:58 UTC] lists+php at box dot cz
No, you're simply WRONG:

"->All symbolic
links are resolved, so it's not possible to avoid this restriction with
a symlink.<-"

because my open_basedir is set to: 

"/home/wejn/x/docs/html:/home/wejn/x/docs1/html"

therefore the file lies in basedir either way, when I call:

copy("/home/wejn/x/docs/html/x", "/home/wejn/x/docs/html/y");

It's a bug and I would expect someone with email "@php.net" to at least READ MY BUGREPORT. I feel a bit stupid when I have to repeat myself over and over again, because you simply assume from beginning that I'm wrong (and the only action you do is actually telling me bullshit about RTFM).

I did RTFM, but your implementation simply doesn't correspond with the things written in TFM.

[offensive]
Anyway, I don't care about PHP anymore - I have better things to do than pushing you to at least read what you're responding to ... btw, responding to bugreports after 2 months is really, really wonderful. Better than never, though.
[/offensive]
 [2004-11-28 17:28 UTC] tony2001@php.net
Using "/home/wejn/x/docs/html:/home/wejn/x/docs1/html" as value of open_basedir is senseless, as it's similar to "/home/wejn/x/docs/html:/home/wejn/x/docs/html", because open_basedir's values are resolved too.

Obviously PHP cannot resolve "/home/wejn/x/docs1/html/y" as it even doesn't exist, so it compares non-existing "/home/wejn/x/docs1/html/y" to "/home/wejn/x/docs/html/" and reports that they aren't the same.

Please, stop reopening this report and begin to respect people that wasting their own free time to help you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 13:01:28 2024 UTC