php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #61114 Bizarre interaction with php.ini not setting include_path
Submitted: 2012-02-16 21:24 UTC Modified: 2013-02-18 00:35 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: bk2 at me dot com Assigned:
Status: No Feedback Package: PHP options/info functions
PHP Version: 5.3.10 OS: *nix
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: bk2 at me dot com
New email:
PHP Version: OS:

 

 [2012-02-16 21:24 UTC] bk2 at me dot com
Description:
------------
include_path was not being set as shown by phpinfo.php
from php.ini
Its stuck at
include_path	.:/usr/lib/php	.:/usr/lib/php

<skipping diagnostic saga>

If you ALSO change (per below), you lose the ability to alter include_path

disable_functions = 
to
disable_functions = (unlink, rmdir, fopen, dio_open, scandir, dir, 
opendir,chdir, chroot, getcwd,
     finfo_open, copy, delete, dirname, file_exists, file_get_contents, 
file_put_contents, file, 
     ftruncate, fwrite, lchgrp, lchown, is_dir, link, mkdir, move_uploaded_file, 
pathinfo, popen,
     readfile, readlink, realpath, rename, symlink, tempnam, tmpfile, touch, 
umask,
     xdiff_file_bdiff, xdiff_file_diff, xdif_file_merge3, xdiff_file_patch)

Test script:
---------------
// in php.ini set
include_path = /xyz/abc
//AND
disable_functions = (unlink, rmdir, fopen, dio_open, scandir, dir, opendir,chdir, chroot, getcwd,
     finfo_open, copy, delete, dirname, file_exists, file_get_contents, file_put_contents, file, 
     ftruncate, fwrite, lchgrp, lchown, is_dir, link, mkdir, move_uploaded_file, pathinfo, popen,
     readfile, readlink, realpath, rename, symlink, tempnam, tmpfile, touch, umask,
     xdiff_file_bdiff, xdiff_file_diff, xdif_file_merge3, xdiff_file_patch)

Expected result:
----------------
run phpinfo.php
it should show
include_path /xyz/abc /xyz/abc

Actual result:
--------------
phpinfo.php

Is stuck at
include_path	.:/usr/lib/php	.:/usr/lib/php

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-02-16 21:26 UTC] rasmus@php.net
Near the top of your phpinfo() output it says:

Loaded Configuration File: /path/to/your/php.ini

Does that show the right path?
 [2012-02-16 21:26 UTC] rasmus@php.net
-Status: Open +Status: Feedback
 [2013-02-18 00:35 UTC] php-bugs at lists dot php dot 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.
 [2013-02-18 16:04 UTC] bk2 at me dot com
Uhm, I did get an email question that amounted to are you kidding me?
I answered i was. 
As far as I know it still happens.

The one thing I might add is that it is possible it had a Return character in
the disable_functions line. I have found that bug separately, that php.ini 
parsing errors are not reported even in the php error log.
I'd argue that should not be a parsing error, as it is kind of silly to require 
a possibly very long list to be all on one line.
If so, php failed silently, and my other settings,
such as open_basedir were set. 
That is, it did not completely fail to apply the .ini changes.

My guess would be that one of the disabled functions was necessary to change the 
path, but used by the PHP interpreter system directly, as opposed to used during 
interpretative php source code.

I'd further assume that in applying settings from php.ini , the 
disable_functions directive is actually processed before the include_path 
directive.

Clearly, no function that can be listed in disable_functions should be used by 
the interpreter, except as a direct call from PHP source.

There must be a layer for the php function calls which call a lower layer
system call. Otherwise, disabling functions can cause the system to fail in 
unexpected ways, like this.

My guess would be that setting the include path calls one of the directory 
related functions, such as chdir.

I see that the path names are duplicated, I expect that is because
my editor turned them into links which were stripped out when i pasted into the 
bug system. Otherwise, the example below should be reproducible in a couple 
minutes.
 [2013-10-01 05:34 UTC] dmptrcks at gmail dot com
found a / right at the start of the file, just before the [PHP]
 [2013-10-01 19:57 UTC] bk2 at me dot com
When I encountered the problem it went away by commenting out the disable functions line and came back by removing comment.
In other words, the file was being parsed as php.ini.

I have since encountered other problems when disabling specific php functions by name. Say function foo is a php builtin function, then some feature of php which would use a similar function, as in thiis case file system related, would stop working.

This leads me to the conclusion that foo_internal is being called both by the interpreter to perform foo from php source code, and by other parts of the interpreter which need the same functionality. For example, reading a directory
may be required by some <read directory> php function, but also may be required by the interpreter to look up a file for include.

I surmise there is not a clear distinction between which functions are ONLY called as internal implementations of php functions, and other operations the interpreter must do. so by disabling <foo>, foo_internal is disabled, but foo_internal is also incorrectly used from other locations in the interpreter. 
In general, all the foo_internal functions should only be referenced from one place, and if their function is needed elsewhere, their should be another layer, for example foo_implementation, which is called by foo_internal, if it is not disabled. This is little more than an educated guess, but it does explain the behavior, if functions are used both as interpreter implementations for foo, and for unrelated bookkeeping/internal functions in the interpreter.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 06 13:01:29 2024 UTC