php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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 Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: lists+php at box dot cz
New email:
PHP Version: OS:

 

 [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

Pull Requests

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: Sun Dec 22 11:01:30 2024 UTC