|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65069 GlobIterator fails to access files inside an open_basedir restricted dir
Submitted: 2013-06-20 14:48 UTC Modified: 2022-07-29 16:14 UTC
Avg. Score:4.1 ± 0.9
Reproduced:10 of 10 (100.0%)
Same Version:3 (30.0%)
Same OS:4 (40.0%)
From: Assigned: bukka (profile)
Status: Closed Package: SPL related
PHP Version: 5.5.0RC3 OS: Windows7
Private report: No CVE-ID: None
 [2013-06-20 14:48 UTC]
GlobIterator fails to access files present in a valid directory when an open_basedir restriction is in effect. Even if the dir is inside the open_basedir restriction it fails.

Test script:
ini_set('open_basedir', __DIR__);

var_dump(iterator_to_array(new GlobIterator(__DIR__.'/*.php')));

Expected result:
Two lists of php files in the current dir.

Actual result:
The glob() call returns a list of files, then the GlobIterator explodes with:

UnexpectedValueException: GlobIterator::__construct(): open_basedir restriction in effect. File(glob://C:\Users\seld/*.php) is not within the allowed path(s): (C:\Users\seld) in C:\Users\seld\test.php on line 6


Add a Patch

Pull Requests

Pull requests:

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-20 17:11 UTC]
-Status: Open +Status: Feedback
 [2013-06-20 17:11 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

Tried your snippet on CLI, but there's no behaviour you describe. I see a proper listing in both 
cases. There must be something else causing this.
 [2013-06-20 17:56 UTC] jamie at media32 dot ca
I think I can reproduce this. It only happens when the GlobIterator is used 
inside the destructor, and the script is run using Apache/Mod PHP (running via 
CLI returns the correct results).

ini_set('display_errors', 1);
ini_set('open_basedir', __DIR__);

class Globber
	public function __destruct()
		var_dump(glob(__DIR__ . '/*.php'));
		var_dump(iterator_to_array(new \GlobIterator(__DIR__ 

$globber = new Globber;

When running via Apache/Mod PHP an UnexpectedValueException is thrown.
 [2013-06-20 17:59 UTC]
On CLI I also get the same problem, Win7 x64 + PHP 5.5.0RC3 or 5.4.3. 

With PHP 5.3.5 and 5.4.6 on linux it works fine though. Seems it might be windows specific. Although as Jamie says it can maybe be triggered in other ways than using windows.
 [2013-06-20 18:01 UTC] jamie at media32 dot ca
I forgot to mention in my previous comment that I'm running PHP 5.4.14 on OSX 
 [2013-06-20 19:04 UTC]
Ok, inside destructor it reproducible for me on windows CLI, that's already 
something one can debug :) But the original snippet still doesn't fail that way. 
And trying DirectoryIterator at that play it works ... so most likely GlobIterator 
is broken somehow.
 [2013-06-21 15:15 UTC]
-Status: Feedback +Status: Analyzed
 [2013-06-21 15:15 UTC]
Ok, the issue is much more complicated than it looks. This is a very tricky case 
because the glob pattern check against the open_basedir value obviously makes no 
sense. The implementation of the glob function is simply to

- expand the pattern
- iterate checking for basedir restriction on every item
- discard result and return false if one of them was not within basedir

What's going on in GlobIterator is to check the basedir against the pattern in 
__construct, that obviously will never work properly. Also, glob extends 
Filesystem iterator, only __construct() and count() methods are implemented. 

Two solutions come in my mind:

- do the same teh glob() function does, do the work in construct and throw 
exception if one of the paths isn't allowed (but that means doing the work 
twice), so no go
- impement the necessary methods in GlobIterator, like current(), next(), etc. 
.. this seems more plausible, however the situation where a value isn't within 
basedir, what would for instance current() return? false? ... 

Looks like a big behavior change anyway. Any ideas for a better fix?

 [2013-06-21 15:33 UTC]
Ah, just to mention, GlobIterator is the same as DirectoryIterator('glob://....') 
... so that on is broken too.
 [2022-01-04 17:49 UTC] epinci at tiscali dot it
Hello, I'm still hitting this one on Windows with PHP 7.4.27 and 8.1.1.
Has this ever been fixed?

Thank you.
 [2022-07-26 11:54 UTC]
The following pull request has been associated:

Patch Name: Fix #65069: GlobIterator incorrect handling of open_basedir check
On GitHub:
 [2022-07-28 10:45 UTC]
Automatic comment on behalf of bukka
Log: Fix #65069: GlobIterator incorrect handling of open_basedir check
 [2022-07-28 10:45 UTC]
-Status: Analyzed +Status: Closed
 [2022-07-29 16:14 UTC]
-Assigned To: +Assigned To: bukka
 [2022-07-29 16:14 UTC]
Just for the record this went just to PHP 8.2 as there is a minor BC break - it will return empty array instead of open_basedir error if pattern is outside.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Apr 21 12:01:29 2024 UTC