Re: Re: glob() bug 47358
| From: | Jakub Zelenka | Date: | Fri, 15 Aug 2014 19:18:48 +0000 |
| Subject: | Re: Re: glob() bug 47358 | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-76568@lists.php.net to get a copy of this message | ||
Hi,
On Fri, Aug 15, 2014 at 7:59 PM, Stas Malyshev <smalyshev@sugarcrm.com>
wrote:
> Hi!
>
> > The source of the problem is that the open_basedir will always leek
> > information about dirs that the user is not suppose to see (out of the
> > open_basedir restriction). The reason is that false value can indicate
> > that (more info in the PR or
> > https://bugs.php.net/bug.php?id=65489 ).
> > However not sure if it's so big issue as no one should ever use
> > open_basedir in security context anyway... :)
>
> The biggest problem with glob() was not security but the fact that it
> returned false on non-existing files when open_basedir is set, even when
> everything is inside open_basedir context. Ideally, glob() should return
> the same with and without open_basedir, with added restriction that if
> open_basedir disallows access to some dir/file, then this dir/file does
> not exist for the purposes of glob(). I'm not sure though if glob() does
> that right now completely or how hard it would be to fix it, I didn't
> look into it deeper. I just noticed that a very old bug was not fixed in
> 5.4/5.5 by mistake, and this bug makes usage of glob with open_basedir
> very annoying, as you can not use glob() in foreach() anymore.
>
The Pierre's commit is fine. It fixes the problem that you just described.
So well done for backporting it... ;)
However the second commit from Anatol is unrelated to the Pierre's and
doesn't really fix anything. It was probably forgotten there when we all
forgot about that problem... :)
Anyway there are probably more important things than securing open_basedir
that is not secure anyway :)
Cheers
Jakub