Edit report at https://bugs.php.net/bug.php?id=47358&edit=1

 ID:                 47358
 Patch added by:     paj...@php.net
 Reported by:        php at guggemand dot dk
 Summary:            glob returns error, should be empty array()
 Status:             Assigned
 Type:               Bug
 Package:            Safe Mode/open_basedir
 Operating System:   FreeBSD 7.1
 PHP Version:        5.2.9RC1
 Assigned To:        pajoye
 Block user comment: N
 Private report:     N

 New Comment:

The following patch has been added/updated:

Patch Name: open_basedir_error_fix
Revision:   1318179021
URL:        
https://bugs.php.net/patch-display.php?bug=47358&patch=open_basedir_error_fix&revision=1318179021


Previous Comments:
------------------------------------------------------------------------
[2011-10-09 16:39:03] paj...@php.net

I agree, there is no error here but a wrong test. I will fix it soonish, 
checking 
the logic in there.

------------------------------------------------------------------------
[2011-10-04 14:32:45] harald dot lapp at gmail dot com

It seems to me, that "glob" is returning false, even though the path i try to 
glob 
is valid compared to the "open_basdir" settings. Could you please have a 
further 
look at this issue?

(tried this with php 5.3.6 and php 5.3.8, btw.)

------------------------------------------------------------------------
[2009-02-12 10:52:09] php at guggemand dot dk

"an empty array if no file matched" is what i see in the manual.
but this returns error, and not an empty array()

glob("/path/allowd/in/open_basedir/nonexitentfile.*"); 

I can understand why a system glob call returning no files, and a call 
returning only nonallowed files has to be treated the same.

But im to dumb to see the logic in treating both as errors instead of "no files 
matched", especially because that breaks existing code.
And treating it as "no files matched" doesnt break anything.
Please enlighten me if im wrong, and ill put on my pointy hat and sit in the 
corner for the rest of the day.

But now i have link i can give the users telling me my servers doesn't work 
right. So i guess i can live with that.

------------------------------------------------------------------------
[2009-02-11 14:20:51] il...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The function is documented to return FALSE on error. There is no problem 
here...

------------------------------------------------------------------------
[2009-02-11 08:12:10] php at guggemand dot dk

Description:
------------
glob() cant be used directly in foreach when open_basedir is set.

i found #41655 which is about the change causing this, and a few other closed 
tickets with "not a bug" as answer.

But that change destroys foreach(glob("nonexistent*") as ... when using 
open_basedir, and the following comment in dir.c states that should be usable.

/* Some glob implementation simply return no data if no matches
   were found, others return the GLOB_NOMATCH error code.
   We don't want to treat GLOB_NOMATCH as an error condition
   so that PHP glob() behaves the same on both types of
   implementations and so that 'foreach (glob() as ...'
   can be used for simple glob() calls without further error
   checking.
*/

As far as i can tell the right thing to do would be to return an empty array 
both when using glob("/etc/hosts") and glob("/etc/nonexistent") when 
open_basedir is used. Or what am i missing?

Ive been using the following patch, and as far as i can tell its not possible 
to check if a file exists when open_basedir is used, and 
foreach(glob("nonext*")) works correctly.

http://gugge.dlx.dk/ting/php5-patch-dir.c

Reproduce code:
---------------
set open_basedir /documentroot

open /documentroot/test.php with the following content

<? var_dump(glob("nonexistent*")); ?>


Expected result:
----------------
array(0) {
}


Actual result:
--------------
bool(false) 


------------------------------------------------------------------------



-- 
Edit this bug report at https://bugs.php.net/bug.php?id=47358&edit=1

Reply via email to