Re: Re: glob() bug 47358
| From: | Jakub Zelenka | Date: | Fri, 15 Aug 2014 18:46:43 +0000 |
| Subject: | Re: Re: glob() bug 47358 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-76565@lists.php.net to get a copy of this message | ||
Hi,
On Fri, Aug 15, 2014 at 2:19 AM, Stas Malyshev <smalyshev@sugarcrm.com>
wrote:
> Hi!
>
> > Sorry, I missed that one. I suspect it was the time where I
> > misconfigured git and branches did not get merged. Feel free to merge
> > it back/backport as I won't be able to do it before Monday.
>
> OK, I have backported it (and following Anatol's patches for it).
>
The Anatol patch (
https://github.com/php/php-src/commit/ad492ca9327fc9f7f0ea7a0ddd32e62cdf0c9137)
is actually wrong. I remember that we discussed in the PR 398. The
open_basedir cannot be changed from $path/... to /tmp (it's not tightening).
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 ). The
solution would be to either return empty array instead (it could be
considered as a BC break) or re-implement glob. The re-implementaion could
be also interesting for perf (removing double allocations - glob + zval)
when used for dirs with many items but that would be quite an effort which
I'm not sure it's worth it... :).
However not sure if it's so big issue as no one should ever use
open_basedir in security context anyway... :)
Cheers
Jakub