• Introducing WebPros Cloud - a fully managed infrastructure platform purpose-built to simplify the deployment of WebPros products !  WebPros Cloud enables you to easily deliver WebPros solutions — without the complexity of managing the infrastructure.
    Join the pilot program today!
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.

Plesk - PEAR - open_basedir - includes

C

chickenbak

Guest
I am running into a little problem with includes and open_basedir.

This is the error that I am getting.

Code:
[client x] PHP Warning: main() [<a href='function.main'>function.main</a>]: open_basedir restriction in effect. File(/php/includes/symfony/symfony/pear.php) is not within the allowed path(s): (/var/www/vhosts/twisi.com:/tmp:/usr/share/pear) in /var/www/vhosts/twisi.com/symfonyapps/test/myapp/config/config.php on line 16 
[client x] PHP Warning: main(symfony/symfony/pear.php) [<a href='function.main'>function.main</a>]: failed to open stream: Operation not permitted in /var/www/vhosts/twisi.com/symfonyapps/test/myapp/config/config.php on line 16 
[client x] PHP Warning: main() [<a href='function.include'>function.include</a>]: Failed opening 'symfony/symfony/pear.php' for inclusion (include_path='.:/php/includes:/usr/share/pear') in /var/www/vhosts/twisi.com/symfonyapps/test/myapp/config/config.php on line 16 
[client x] PHP Fatal error: Uncaught exception 'Exception' with message 'Unable to find symfony librairies' in /var/www/vhosts/twisi.com/symfonyapps/test/myapp/config/config.php:18\nStack trace:\n#0 /var/www/vhosts/twisi.com/symfonyapps/test/myapp/config/config.php(18): unknown()\n#1 /var/www/vhosts/twisi.com/symfonyapps/test/web/index.php(8): require_once('/var/www/vhosts...')\n#2 {main}\n thrown in /var/www/vhosts/twisi.com/symfonyapps/test/myapp/config/config.php on line 18

It works beautifully without open_basedir on...now here is the key...it seems that by utilizing the includes directory, it triggers open_basedir to kick it back...even though /usr/share/pear is within the include AND the open_basedir.

Question is...without actually going in and mandating the include be /usr/share/pear/symfony/symfony/pear.php (that defeats the purpose of the include) is there any way to make open_basedir "like" the include request...or am I getting this all wrong?
 
Can you give a little more details? What PEAR class are you trying to use? And how are you calling the class and functions you are trying to use?
 
Symfony is what I am trying to call, it is being called as an include( 'symfony/symfony/pear.php' );

Its actual location is /usr/share/pear/symfony/symfony/pear.php, so it is correctly called, and correct in the include path as well as open_basedir.

Earlier today I found a similar bug that was still in the 5.0.4 version that could be indicative of it being a PHP bug. The prefixing of /php/includes kind of throws me for a loop, because the directory doesn't exist, and nowhere in the code is /php/includes explicitly stated.
 
Seems that it should work. I don't have any experience with that class. If you do mandate the include to be /usr/share/pear/symfony/symfony/pear.php does it work? Just wondering.
 
That is the interesting thing...it works fine at that point...

If I turn off open_basedir, it works fine

if I set the path directly to the file, it works fine

So, both the include path and the open_basedir seem to be working fine independantly, but when in conjunction with one another, they fail.
 
hmm. That does seem weird. Do other PEAR classes work like they should?
 
I actually confirmed that it was a PHP bug last night through some testing...I think it was fixed after 5.0.4...which is probably a well used version considering that that is the latest available for CentOS/RHEL RPMs.

I believe this bug to be the culprit...

http://bugs.php.net/bug.php?id=31054
 
Back
Top