1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

Plesk - PEAR - open_basedir - includes

Discussion in 'Plesk for Linux - 8.x and Older' started by chickenbak, Jan 16, 2006.

  1. chickenbak

    chickenbak Guest

    0
     
    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?
     
  2. chickenbak

    chickenbak Guest

    0
     
    bumpity bump bump :(
     
  3. troymc

    troymc Guest

    0
     
    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?
     
  4. chickenbak

    chickenbak Guest

    0
     
    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.
     
  5. troymc

    troymc Guest

    0
     
    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.
     
  6. chickenbak

    chickenbak Guest

    0
     
    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.
     
  7. troymc

    troymc Guest

    0
     
    hmm. That does seem weird. Do other PEAR classes work like they should?
     
  8. chickenbak

    chickenbak Guest

    0
     
    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
     
Loading...