Re: Re: glob() bug 47358

From: 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

« previous php.internals (#76565) next »