php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #25194 require() not findings files when "." is in include_path
Submitted: 2003-08-21 11:00 UTC Modified: 2003-08-29 09:24 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: ri at kamp dot de Assigned:
Status: No Feedback Package: Filesystem function related
PHP Version: 4CVS-2003-08-21 (stable) OS: Solaris 8
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: ri at kamp dot de
New email:
PHP Version: OS:

 

 [2003-08-21 11:00 UTC] ri at kamp dot de
Description:
------------
require cannot open a file in the same directory as the calling script [like require('./includefile.php')]. All dirs in the path have permission 755. OS is solaris 8, documentroot mounted as NFS, include_path has "." within. In the case this happens also getcwd() or passthru("/bin/pwd") gives no result but passthru("/bin/ls") list the "current" dir.

The function expand_filepath in main/fopen_wrappers.c gets an empty result when calling VCWD_GETCWD(cwd, MAXPATHLEN);

This may not be a php bug (maybe solaris8 or nfs) but occurs only within php. As workaround I changed expand_filepath to:
------------------
        int cwd_pos;

        result = VCWD_GETCWD(cwd, MAXPATHLEN);  
        if (!result) {
                //cwd[0] = '\0';
                php_error_docref(NULL TSRMLS_CC, E_WARNING, 
                        "cwd not working for %s",SG(request_info).path_translated);
                strlcpy(cwd, SG(request_info).path_translated, sizeof(cwd));
                cwd_pos = strlen(cwd) - 1;

                /* Strip filename */
                while (!IS_SLASH(cwd[cwd_pos])
                                && (cwd_pos >= 0)) {
                        cwd[cwd_pos--] = 0;
                }
        }
------------------

I know this is no final solution but the scripts work thereafter. 

Reproduce code:
---------------
include_path = ".:/usr/local/lib/php"
documentroot = "/home/htdocs"
script is in /home/htdocs/ (documentroot)

<? require('./somefile.php'; ?>

or

<? require('somefile.php'; ?>

Actual result:
--------------
Fatal error: main(): Failed opening required './somefile.php' (include_path='.:/usr/local/lib/php')

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-08-21 19:04 UTC] sniper@php.net
Works fine under Linux..but I don't have any NFS mount to work with. Can you check if this happens only with the NFS?

 [2003-08-22 00:04 UTC] ri at kamp dot de
Yes it seems to be nfs related since includes on a local disk (phpmyadmin) work well.
 [2003-08-22 02:27 UTC] sniper@php.net
What is the output of '/bin/pwd' when you run it in shell,
in the directory in question? 

(my guess it is wrong too, in which case this really is not any PHP bug but yet another Solaris bug)

Also, if leaving "." out of the include_path solves this, I don't see any reason why we should worry about this too much.

 [2003-08-22 03:21 UTC] ri at kamp dot de
The output of /bin/pwd is correct if executed from the shell (even as user nobody). Also leaving out "." from include_path does not solve the problem but behaves different:
1.)
ini_set("include_path","/usr/local/lib/php");
require("somefile.php");
works but it should not (or am I wrong?)
2.)
ini_set("include_path","/usr/local/lib/php");
require("./somefile.php");
does not work even if its nearly the same

also other commands (e.g. show_source) have problems.

I can send you a link in private mail if you like to see the results

Maybe its a solaris or apache bug but it seems to hit only php, so there may be reasons to solve the problem (if not a bug) in php.
 [2003-08-22 10:57 UTC] ri at kamp dot de
I just found the one missing last directory without read permission and start to retire into my shell. I was shure that  I checkd them all because I read about the corresponding problem. shame on me.
 [2003-08-22 19:11 UTC] sniper@php.net
Why did you change the status to 'Duplicate' ?

 [2003-08-24 04:42 UTC] ri at kamp dot de
sorry I didn't notice that. Must have been an accidental click
 [2003-08-24 08:20 UTC] sniper@php.net
Could you also explain your previous comment about 'last directory not having read permission' ??

 [2003-08-29 09:24 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Dec 30 14:01:28 2024 UTC