Maybe this isn't directly related, but  
fopen($myfilename,"r") also fails, even though  
include($myfilename) works.  Again, $myfilename is in the  
safe_mode_include_dir, so fopen should be able to open it.

What are the permissions of all the directories in that path?
(/var/lib/php_packages/)

From memory, all files were mode 664 and all directories 
had permissions of 775 being owned by root:root.  However, 
I no longer have that same structure to prove that.  If 
you like, I can setup an almost identical test case using 
the code that I included below (but using my new 
structure).

Ok, here's a new "complete" example for you.   
   
First, we need to do some setup as this is based on   
permissions, ownership, and safe mode:   
   
cd <some directory in safe_mode_include_dir>   
# note, I used cd /usr/share/pear   
echo "TESTING" > commonfile.php   
chmod a+r commonfile.php  
   
Then: $ ls -l commonfile*   
-rw-rw-r--    1 root     root            8 Aug 10 10:54   
commonfile.php   
  
And, permissions on the source PHP file in use:  
$ ls -l bug31618.php  
-rw-rw-r--    1 kpederson financialaid      576 Aug 10  
10:50 bug31618.php  
  
I used the following relevant settings:  
  
$ grep -iE "safe|include" /etc/php.ini | grep -v "^;"  
safe_mode = On  
safe_mode_gid = On  
safe_mode_include_dir = /usr/share/pear  
safe_mode_exec_dir = "/usr/local/php_exe/bin"  
safe_mode_allowed_env_vars = PHP_  
safe_mode_protected_env_vars = LD_LIBRARY_PATH  
include_path =  
".:/usr/share/pear/:/usr/share/pear/ewu_lib:/var/lib/php_secure"  
sql.safe_mode = Off  
  
Now, grab my PHP script from the following URL:  
  
http://www.ewu.edu/web/tools/bug31618.php.txt  
  
It's output looks like the following (as can be seen from  
http://www.ewu.edu/web/tools/bug31618.php):  
  
is_readable: /usr/share/pear/commonfile.php (false)  
TESTING   
  
Now, if I change the ownership to root:root (as I did for  
bug31618_2.php, eg. as seen by  
http://www.ewu.edu/web/tools/bug31618_2.php):  
  
is_readable: /usr/share/pear/commonfile.php (true)  
TESTING   
  
Thus, the results are based on ownership of the calling 
php script, not the file attempting to be read, despite 
being in safe_mode_include_dir.

Could you plz also try this:
<?php
fopen($myfilename, 'r');
?>
And post the error message here.
Thanks.

Of course, I meant this:
<?php
$myfilename = '/usr/share/pear/commonfile.php';
fopen($myfilename, 'r');
?>

Ok.  It says (see 
http://www.ewu.edu/web/tools/bug31618_3.php): 
 
Warning: fopen() [function.fopen]: SAFE MODE Restriction 
in effect. The script whose uid/gid is 687/694 is not 
allowed to access /usr/share/pear/commonfile.php owned by 
uid/gid 0/0 in /var/www/sites/web/tools/bug31618_3.php on 
line 3 
  
 Warning: fopen(/usr/share/pear/commonfile.php) 
[function.fopen]: failed to open stream: Resource 
temporarily unavailable 
in /var/www/sites/web/tools/bug31618_3.php on line 3

Did you read something about safe_mode before turning it On?

"By default, Safe Mode does a UID compare check when opening files. If you want to relax this to a GID compare, then turn on safe_mode_gid. Whether to use UID (FALSE) or GID (TRUE) checking upon file access." (c) http://www.php.net/manual/en/features.safe-mode.php

So, it's perfectly fine to have these errors and to have FALSE in is_readable() because you turned safe_mode yourself.
This is expected behaviour.

Yes.  I read docs, although I sometimes misunderstand   
them:   
   
Note in my previous post:   
safe_mode_include_dir = /usr/share/pear     
  
Also note that per the documentation  
(http://www.php.net/manual/en/features.safe-mode.php):  
  
"safe_mode_include_dir string  
UID/GID checks are bypassed when including files from this  
directory and its subdirectories (directory must also be  
in include_path or full path must including)." 
  
Certainly  $myfilename = '/usr/share/pear/commonfile.php'; 
is in safe_mode_include dir. 
 
Thus, the error message is incorrect and *is* a PHP bug.

Please try this patch:
http://tony2001.phpclub.net/dev/tmp/bugs_29840_31618.diff
(with the latest snapshot/CVS).

Ok, I tried it out on my dev server and it works!  
is_readable() now returns the correct values based on the 
ownership of the file. 
 
From my initial test: 
 
is_readable: /var/lib/php/test_templ2.php (true) 
TEST 
 
The fopen($myfilename) call, however, still fails with the 
following error message (perhaps I should file this as a 
separate bug report...): 
 
Warning: fopen() [function.fopen]: SAFE MODE Restriction 
in effect. The script whose uid/gid is 49/49 is not 
allowed to access /var/lib/php/test_templ2.php owned by 
uid/gid 0/0 in /var/www/sites/devel/test.php on line 10 
  
 Warning: fopen(/var/lib/php/test_templ2.php) 
[function.fopen]: failed to open stream: Success 
in /var/www/sites/devel/test.php on line 10 
 
And... safe_mode_include_dir on that server is set 
to /var/lib/php.

Yes, I've made this intentionally.
The file in safe_mode_include_dir can be included, but cannot be opened using fopen() and friends.
IMO that's why this directive is called safe_mode_*INCLUDE*_dir.

Hmm... I can understand that logic.  The docs say:    
    
"UID/GID checks are bypassed when including files from    
this directory and its subdirectories"    
    
which also seems to fit.    
  
It's going to make it really hard for me (and I would    
guess many others) as a developer to support a given use   
case.  
  
The use case that doesn't seem to be satisfied by this is    
when the files in the safe_mode_include_dir (smarty for   
example) needs to fopen() other files in that directory.    
Smarty tries is_readable, which now succeeds, but there is  
no way for smarty, when running under safe mode, to  
actually read common templates... <sigh>.  I don't know if  
this use case can be satisfied without that  
functionality.... I have hundreds of users, but no  
apparent way, (other than includes which now work) to do  
any type of complex templating.  In most commercial  
environments, this wouldn't seem like a problem, but in  
the university setting, they all need access to a common  
template.  
  
Ok.  I'm ranting and a bit frustrated -- although I do  
admit that you're right per all the docs.  Feel free to  
delete this message and close the bug report.  I  
appreciate you leaving it open a bit longer. If you're 
open for any discussion, you can e-mail me. 
  
Thanks.

This is the reason why safe_mode should have been nuked long time ago.

Hmm... wouldn't something like safe_mode_read_dir make it  
possible to have shared libraries while using safe mode,  
assuming it allowed fopen(), include/require access?  
  
I don't see how else it's possible to make common modules,  
like the pear library, available globally, unless they  
never need to do more than include other files in their  
own hierarchy, while using safe mode.  
  
To turn off safe mode, would be a huge security risk  
unless I were running it using suExec and CGI or  
something.  
  
I'm going to ask on #PHP for other thoughts as there has  
to be a way to get the best of both worlds (common  
accessible libraries vs. security).  Thanks for the help.

Could someone tell me what will happened to this report ? is this supposed to be solved in a future version of PHP ? I have the same problem with smarty in a commercial application. Is there another way to make it work with safe_mode on ?

Thanks a lot.

Guys... that is what open_basedir is actually for. 
Cheers,
Nstiac

Just need to read a bit =) 
Nstiac

http://www.php.net/manual/en/features.safe-mode.php#ini.sect.safe-mode

open_basedir does not do what I need it to do.  The 
functionality and setup that I need:

1) I have many users per host, each with their own group 
hierarchy.
2) Each user cannot access any other users data, unless 
they are in the same group.  Thus, I have user and group 
permissions that need to be managed.
3) I have common scripts that everyone needs to access 
(smarty templates and wrappers).

Because of #1 and #2, I need safe mode with GID checking. 
Because of #3, I need to have a directory that *everyone* 
can include and read from -- safe_mode_include_dir is not 
sufficient because it doesn't allow the users to read the 
templates, only include them and smarty (smarty.php.net) 
needs the ability to read them in order for them to work.

open_basedir is great for restricting reads between hosts. 
I could set it to /path/to/host/;/path/to/templates/ and 
then users would only be able to access files within their 
host and the templates, but it still doesn't solve the 
problem at hand.

Until an is_includible() is added, it's possible to check a file exists using realpath() even with safe mode enabled which allows Smarty to at least see and include() its own plugins.

Safe mode has been removed as of PHP 5.4.0, so this ticket can be
closed.