php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #3075 inconsistency in checking include_path
Submitted: 1999-12-31 14:35 UTC Modified: 2000-10-16 10:54 UTC
From: djm at web dot us dot uu dot net Assigned:
Status: Closed Package: *General Issues
PHP Version: 4.0 Beta 3 OS: all
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: djm at web dot us dot uu dot net
New email:
PHP Version: OS:

 

 [1999-12-31 14:35 UTC] djm at web dot us dot uu dot net
I'm trying to track down exactly what document_root does, and under what circumstances.  I found the following inconsistency:
If PHP3_URL_FOPEN is defined, then php3_fopen_wrapper runs php3_fopen_url_wrapper, which does:
                if (options & USE_PATH) {
                        fp = php3_fopen_with_path((char *) path, mode, PG(include_path), NULL);

Otherwise, it runs
        if (options & USE_PATH && PG(include_path) != NULL) {
                return php3_fopen_with_path(path, mode, PG(include_path), NULL);

It seems to me that those two if statements should be identical, so the semantics of include_path and document_root don't depend on whether PHP3_URL_FOPEN is defined.
I don't know which one is what was intended, however.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [1999-12-31 16:28 UTC] djm at web dot us dot uu dot net
I now believe that both of those if statements are wrong.  php3_fopen_with_path should always be run, because it is the only place that checks doc_root.  Experimenting shows that the PHP function fopen does not use doc_root, at least when configured the way I have it.  
If include_path is not set, php3_fopen_wrapper does the same thing as the alternative code blocks in these two statements, so those blocks are redundant.
(BTW, I do have safe_mode on, and open_basedir set to the same value as doc_root.)

Also, the check in php3_fopen_with_path for a relative file name is wrong, because it fails for files with names like ".cshrc" or "....", and it doesn't handle ".." either.

Here are patches to make it work the way it seems to me it should.

--- fopen-wrappers.c    1999/12/30 22:31:12     1.1.1.2
+++ fopen-wrappers.c    1999/12/31 21:26:54
@@ -194,16 +194,7 @@
        }
 #endif
 
-       if (options & USE_PATH && PG(include_path) != NULL) {
-               return php3_fopen_with_path(path, mode, PG(include_path), NULL);
-       } else {
-               if(!strcmp(mode,"r") || !strcmp(mode,"r+")) cm=0;
-               if (options & ENFORCE_SAFE_MODE && PG(safe_mode) && (!_php3_checkuid(path, cm))) {
-                       return NULL;
-               }
-               if (_php3_check_open_basedir(path)) return NULL;
-               return fopen(path, mode);
-       }
+       return php3_fopen_with_path(path, mode, PG(include_path), NULL);
 }
 
 #if CGI_BINARY || FHTTPD || USE_SAPI
@@ -324,8 +315,9 @@
        if (opened_path) {
                *opened_path = NULL;
        }
-       /* Relative path open */
-       if (*filename == '.') {
+       /* Relative path open; never use path */
+       if ((filename[0] == '.' && filename[1] == '/')
+               || (filename[0] == '.' && filename[1] == '.' && filename[2] == '/')) {
                if (PG(safe_mode) && (!_php3_checkuid(filename, cm))) {
                        return NULL;
                }
@@ -886,23 +878,8 @@
 
        } else {
                PLS_FETCH();
-
-               if (options & USE_PATH) {
-                       fp = php3_fopen_with_path((char *) path, mode, PG(include_path), NULL);
-               } else {
-                       int cm=2;
-                       if(!strcmp(mode,"r") || !strcmp(mode,"r+")) cm=0;
-                       if (options & ENFORCE_SAFE_MODE && PG(safe_mode) && (!_php3_checkuid(path, cm))) {
-                               fp = NULL;
-                       } else {
-                               if (_php3_check_open_basedir((char *) path)) {
-                                       fp = NULL;
-                               } else {
-                                       fp = fopen(path, mode);
-                               }
-                       }
-               }
 
+               fp = php3_fopen_with_path((char *) path, mode, PG(include_path), NULL);
                *issock = 0;
 
                return (fp);

 [1999-12-31 16:38 UTC] djm at web dot us dot uu dot net
I should also mention that I do not have include_path set, in my configuration.
Sorry the patch got mangled; netscape did that when I pasted it in.
I suggest you make the textarea box wider.

 [1999-12-31 16:47 UTC] djm at web dot us dot uu dot net
Here's a slightly more efficient patch for preventing relative paths from being searched for in include_path.

@@ -315,9 +315,10 @@
        if (opened_path) {
                *opened_path = NULL;
        }
-       /* Relative path open; never use path */
-       if ((filename[0] == '.' && filename[1] == '/')
-               || (filename[0] == '.' && filename[1] == '.' && filename[2] == '/')) {
+       /* Relative path; do not search for the file in "path" */
+       if (filename[0] == '.' &&
+               (filename[1] == '/'
+                || (filename[1] == '.' && filename[2] == '/'))) {
                if (PG(safe_mode) && (!_php3_checkuid(filename, cm))) {
                        return NULL;
                }

 [2000-07-29 15:14 UTC] waldschrott@php.net

 [2000-08-01 10:30 UTC] waldschrott@php.net
user feedback: still appearing
 [2000-09-02 22:54 UTC] sniper@php.net
Have you tried latest CVS or snapshot from http://snaps.php.net lately?
If not, please try. And report back whether problem still exists.

--Jani
 [2000-09-21 09:42 UTC] sniper@php.net
No feedback from user.

--Jani
 [2000-09-21 11:22 UTC] djm at web dot us dot uu dot net
Replying to the bug mail fails with "no route to host" for va.php.net, so I'll try posting my reply here.

Why don't the PHP developers check for themselves whether the problem is still there?  I'm tired of having to report PHP bugs 2 or 3 times because the developers wait 8 months before dealing with them.  You can read the code or diff it against the version I reported the bug in as well as I can.  I gave a precise analysis of the problem, which you should be able to understand.  You can see the on 08/01 I reported that the current version still had the problem.  Do you really want me to resubmit the bug report every month until it gets fixed?


 [2000-09-26 04:12 UTC] sniper@php.net
There has been some fixes regarding doc_root problems recently.
Also check this url:

http://marc.theaimsgroup.com/?l=php-dev&m=96914235601714&w=2

I asked you to check the _latest_ CVS or snapshot because I couldn't
reproduce your problem with it.

And yes, if you have not heard of us for a long time you should update
your bug report, especially when there have been releases since you
submitted your report.

So, PLEASE read that document and try latest snapshot from 
http://snaps.php.net

and reply whether it solves your problem.  BTW. Next time, please 
tell us first WHAT the problem is and then submit a patch for it..not the
other way around.

--Jani


--Jani
 [2000-10-16 10:54 UTC] sniper@php.net
This is fixed in PHP4.0.3pl1

--Jani
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC