Re: Re: glob() bug 47358

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

« previous php.internals (#76568) next »