e-accelerator open_basedir errors

[polone@…]

It appears e-accelerator is having problems with open_basedir restrictions. Files that are within the allowed path aren't being honored when the accelerator is enabled but works perfectly fine when disabled.

Warning: Unknown(): open_basedir restriction in effect. File(include/whatever.php) is not within the allowed paths in Unknown on line 0

[hans]

Can you supply us with some more information about your php configuration/setup, exact settings / example php files to reproduce this?

I've just done some testing using:

open_basedir = /home

/home/hans/public_html/test.php:

<?php require("include/b.php");

phpinfo(); ?>

/home/hans/public_html/include/b.php:

<?

echo "test";

?>

and this doesnt give me any trouble.

[bart]

Bug #105 was marked as duplicate

[anonymous]

I'm running PHP 4.4.2 on Redhat Linux FC4 with safe mode. Something that would more closely emulate the situation would be something like:

php.ini: open_basedir = /var/www:/usr/local/lib/php include_path = ".:/usr/local/lib/php"

/usr/local/lib/php/whatever.php: <?php

echo 'wont load';

?>

/var/www/public_html/test.php: <?php

include 'whatever.php';

?>

It seems to affect PHP scripts that are included from files not directly in a localized path.

[bart]

I created exactly the same situation on an FC5 box and I can't load test.php, which is the expected behaviour. I've tried some other open_basedir things and they all work like they should. Anyway, eAccelerator comes after php checks the paths, not before.

I'm going to close this with a "worksforme", if someone has a good way of reproducing this, please let us know!

[mrbig]

excellent, its been fixed.  David Shade

[breun]

It seems eAccelerator is causing open_basedir problems somehow. It's not totally reproducable, but on the Plesk forums people have recommend disabling eAccelerator to solve 500 Internal Server errors in Horde:  http://forum.swsoft.com/showthread.php?t=43131 According to my error_log these are in fact open_basedir errors:

---

PHP Fatal error: Can't load Horde/SessionObjects?.php, open_basedir restriction. in /usr/share/psa-horde/lib/Horde/IMAP/Tree.php on line 311

---

Disabling eAccelerator 0.9.5.3 makes the problem go away. Horde (at least on Plesk) uses different open_basedir settings for different directories. Could it be that eAccelerator somehow caches the open_basedir setting so that the wrong open_basedir path is applied later?

[Roman_iPark]

Hi there,

we have come to reproduce this error on a shared hosting environment where this is an extremely critical bug. I really like eaccelerator but not fixing this problem forces us to switch to another opcode cache.

In VirtualHost? config we use php_admin_value open_basedir /www/home_User1/

script of User1 in /www/home_User1/htdocs/

<?php
ini_set('include_path', /www/home_User2/config);
include('/www/home_User2/config/config.php') //located in /www/home_User2
// warning open_basedir in effect blabla
?>

<?php
ini_set('include_path', /www/home_User2/config);
include('config.php') //located in /www/home_User2
print_r(get_defined_vars);  // prints defined vars of config.php of User2
//
?>

open_basedir check is bypassed when using ini_set('include_path', ...) or php_value include_path include_path in .htaccess and relative includes.

This behavior only occurs if Eaccelerator is enabled AND /www/home_User2/config/config.php is cached by eaccelerator

[hans]

Confirmed. I will look into this one.

[hans]

Fixed in revision @360

[stigm]

This is still a problem in revision 403 of 0.9.6 branch with PHP 5.2.26.

open_basedir is set to "/var/www/vhosts/website.com/project:/tmp"

Fatal error: Can't load /var/www/vhosts/website.com/project/web/index.php, open_basedir restriction. in Unknown on line 0

Turning off EAccelerator causes the index.php page to load correctly, no open_basedir errors.

I have to switch server to APC now, cannot proceed without open_basedir due to company policy.

[hans]

Acknowledged. Problem only exists with EACCELERATOR_USE_INODE. I test/dev/operate only with md5 based cache (--without-eaccelerator-use-inode configure option), that's why i couldn't verify it earlier.

[hans]

Update after some deliberation with Bart: Using open_basedir with EACCELERATOR_USE_INODE will never work, because making it work would take away the advantage of using inodes as reference (because we have to determine the full path of the file requested).

You can solve your problem by compiling eAccelerator with '--without-eaccelerator-use-inode'.

Recent benchmarking has shown us that the advantage of using inodes is negligible anyway, so we decided to entirely strip it from future releases (including our current svn trunk) so this will no longer be a problem.

[hans]

Oh, and don't forget to flush your eaccelerator cache after recompiling with something like:

find /path/to/eaccelerator/cache -type f -exec rm '{}' \;

[bascorp]

 sun pictures

[jodoreps]

 free text hosting  Acheter Generique France Sans Ordonnance, Achat Medicaments bon marche sur internet  Farmacia Espanola , Comprar Genericos En Espana Sin Receta , Compra Medicamentos Por Internet  Medical Assistant - Your Assistant Online  L'Assistant Medical - Ton Assistant en ligne