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 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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/30188
--
Edit this bug report at http://bugs.php.net/?id=30188&edit=1
