BUG Inspect current directory for include_path #916

Merged
merged 1 commit into from Nov 1, 2012

Conversation

Projects
None yet
4 participants
Owner

chillu commented Nov 1, 2012

This fixes problems where require/include calls rely
on the relative file path, e.g. in i18n.php.

Followup from silverstripe#904

@chillu chillu BUG Inspect current directory for include_path
This fixes problems where require/include calls rely
on the relative file path, e.g. in i18n.php.

Followup from #904
a5fd3cf
Owner

halkyon commented Nov 1, 2012

Right, so sometimes the current directory is in the include path, and sometimes not, presumably depending on the hosting situation and how the php.ini include path has been initially set.

Looks good to me. Merging...

@halkyon halkyon added a commit that referenced this pull request Nov 1, 2012

@halkyon halkyon Merge pull request #916 from chillu/pulls/current-dir-include-path
BUG Inspect current directory for include_path
ead563c

@halkyon halkyon merged commit ead563c into silverstripe:3.0 Nov 1, 2012

Contributor

Juanitou commented Sep 7, 2014

This is not resolved yet in all set ups. I have a “multi-sites” one in a shared host with open_basedir enabled, where only one install of SilverStripe is shared between two (or more) sites through symbolic links. Here is the folder schema:
/home/atelierd/
|--- firstdomain/
   |--- private_html/
        |--- cms/
        |--- framework/
        |--- modules/
   |--- public_html/
        |--- assets/
        |--- cms/ --> /home/atelierd/firstdomain/private_html/cms
        |--- framework/ --> /home/atelierd/firstdomain/private_html/framework
        |--- modules/ --> /home/atelierd/firstdomain/private_html/modules
        |--- mysite/
        |--- silverstripe-cache/
        |--- themes/
|--- seconddomain/
   |--- public_html/
        |--- assets/
        |--- cms/ --> /home/atelierd/firstdomain/private_html/cms
        |--- framework/ --> /home/atelierd/firstdomain/private_html/framework
        |--- modules/ --> /home/atelierd/firstdomain/private_html/modules
        |--- mysite/
        |--- silverstripe-cache/
        |--- themes/

This work a treat but I’m getting the following only when visiting pages of the second domain:
Warning at home/atelierd/domains/firstdomain.org/private_html/framework/thirdparty/Zend/Loader.php line 198: is_readable(): open_basedir restriction in effect. File(/usr/local/lib/php/Zend/Translate/Adapter/I18nRailsYamlAdapter.php) is not within the allowed path(s): (/home/atelierd/:/tmp:/var/tmp:/usr/local/php5/lib/php). **(http://www.seconddomain.org/)**

The file exists and is located as expected in:
home/atelierd/domains/firstdomain.org/private_html/framework/i18n/i18nRailsYamlAdapter.php

This is a recently updated 3.1.6 install, without custom code.

I would like to help debug it but I don’t know where to start.

Best regards.

(Should I open a new issue?)

On all Silverstripe 3.1 installs (haven't tried 3.2) I get the issue noted in #916 (comment) - but there is a solution (see below)

In my setups:

PHP message: PHP Warning: is_readable(): open_basedir restriction in effect. File(/usr/share/pear/Zend/Translate/Adapter/I18nRailsYamlAdapter.php) is not within the allowed path(s): (/usr/share/pear/:/usr/share/php/:/other/paths/)

This doesn't make sense as /usr/share/pear/ is in the open_basedir settings so the warning message could point to some deeper issue in PHP.

/usr/share/pear/Zend/Translate/Adapter/I18nRailsYamlAdapter.php does not exist but PHP should not emit a warning about not being able to look in /usr/share/pear/ as the PHP settings specifically allow for it to be accessed. is_readable() in this instance should just return FALSE.

The solution in my instance was to specifically set include_path in the FPM Pool settings to the cwd as PHP sets it by default to ".:/usr/share/pear/:/usr/share/php" when not defined in php.ini

; set with cwd by default as include_path
php_value[include_path] = .

.. then restart/reload FPM

This causes the Zend loader to bypass the two paths that are triggering the open_basedir warning. I don't have anything loading from /usr/share/pear/:/usr/share/php in any case and if I wanted to, I'd load it with the absolute directory, which is best practise any way.
Separately, the Zend loader thing should be using an absolute path in any case, which would bypass an include_path lookup

It doesn't fix the weird issue around having an open_basedir warning about files being accessed in approved paths, just a workaround.

I hope this helps all you Silverstripe devs out there who are getting your logs filled up with lines like this.

Cheers
James

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment