#30188 [Bgs->Csd]: open_basedir check is badly performed under some circumstances
ID: 30188
User updated by: lists+php at box dot cz
Reported By: lists+php at box dot cz
-Status: Bogus
+Status: Closed
Bug Type: Filesystem function related
Operating System: Linux (Gentoo, latest)
PHP Version: 5.0.1
New Comment:
My final words would be:
Function, that does basedir check differently based on (non)existence
of the file (which is) being checked, is flawed.
I'm putting my hands off it ... to ensure your precious time won't be
wasted. After all -1 happy_user/advocate means nothing compared to
solving real issues like adding more entropy to PHP sources or changing
parameter passing again ;-)
Btw, this attitude kinda reminds me "don't live with broken windows"
from "The Pragmatic Programmer" (and if you don't know what that means,
all the more reason not to mess with this [in your opinion absolutely
correct] behaviour of basedir check).
Luckily enough there's enough alternatives to this whole PHP thing.
Previous Comments:
[2004-11-28 17:28:15] [EMAIL PROTECTED]
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.
----
[2004-11-28 16:58:48] 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 15:16:38] [EMAIL PROTECTED]
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-10-14 12:10:46] 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-10-14
#30188 [Bgs->Opn]: open_basedir check is badly performed under some circumstances
ID: 30188
User updated by: lists+php at box dot cz
Reported By: lists+php at box dot cz
-Status: Bogus
+Status: Open
Bug Type: Filesystem function related
Operating System: Linux (Gentoo, latest)
PHP Version: 5.0.1
New Comment:
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]
Previous Comments:
[2004-11-28 15:16:38] [EMAIL PROTECTED]
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-10-14 12:10:46] 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-10-14 11:51:28] 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-09-21 23:50:28] 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:
-
#30188 [Opn]: open_basedir check is badly performed under some circumstances
ID: 30188
User updated by: lists+php at box dot cz
Reported By: lists+php at box dot cz
Status: Open
Bug Type: Filesystem function related
Operating System: Linux (Gentoo, latest)
PHP Version: 5.0.1
New Comment:
> > 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. :)
Previous Comments:
[2004-10-14 11:51:28] 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-09-21 23:50:28] 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
--
Edit this bug report at http://bugs.php.net/?id=30188&edit=1
#30188 [NEW]: open_basedir check is badly performed under some circumstances
From: lists+php at box dot cz
Operating system: Linux (Gentoo, latest)
PHP version: 5.0.1
PHP Bug Type: Filesystem function related
Bug description: open_basedir check is badly performed under some circumstances
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
--
Edit bug report at http://bugs.php.net/?id=30188&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30188&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30188&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30188&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30188&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30188&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30188&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30188&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30188&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30188&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30188&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30188&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30188&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30188&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30188&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30188&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30188&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30188&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30188&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30188&r=mysqlcfg
