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