text: go to bug id or search bugs for
  New Comment:
  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.
  Add a Patch
  Add a Pull Request
  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);
  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.
  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;
  }
  Please verify that it?s still happening using the latest version of PHP (release 4.0.1pl2 or CVS).
  user feedback: still appearing
  Have you tried latest CVS or snapshot from lately?
  If not, please try. And report back whether problem still exists.
  --Jani
  No feedback from user.
  --Jani
  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?
  There has been some fixes regarding doc_root problems recently.
  Also check this url:
  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
  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
  This is fixed in PHP4.0.3pl1
  --Jani