1

On a virtual hosting server I have the open_basedir set to .:/path/to/vhost/web:/tmp:/usr/share/pear for each virtual host. I have a client who's running WordPress and he's complaining about open_basedir errors thus:

PHP WARNING: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/var/lib/php/session/sess_42k7jn3vjenj43g3njorrnrmf2) is not within the allowed path(s): (.:/path/to/vhost/web:/tmp:/usr/share/pear)

So the PHP session save_path isn't included in open_basedir but sessions across all sites on the server seems to be working fine apart from in this intermittent instance. I thought that perhaps the default session handler ignored open_basedir and this warning was caused by WP accessing the session file directly.

However from what I can see PHP 5.2.4 introduced open_basedir checking to the session.save_path config: http://www.php.net/ChangeLog-5.php#5.2.4 (I am on PHP 5.2.13).

Any ideas?

2 Answers 2

0

Create directories (like "phptmp") for the sessions in each of virtual hosts path (preserve permissions and owner), then add session.save_path, upload_tmp_dir for each virtualhost. This is the secure way. If you'll clarify how virtualhosts are defined (control panel, manually) - we can give a more detailed answer.

0

Although the question here was asked a long time ago, Google still seems to be directing a lot of traffic here, and the previous answer is not secure.

I have tested this with PHP 7.2 and 7.4 on Ubuntu. PHP will happily write session data outside of the open_basedir directory using the default handler. It should not work with a custom handler or with older versions of PHP - it might not work in future. So it is therefore good practice to ensure that the session.save_path is within the open_basedir constraint.

If this needs to be inside the document root, then you need to tell the webserver not to allow PHP to execute the PHP in the session.save_path tree. Even if you've told it to only execute PHP in files with a .php extension (there are other pontetial vulnerabilities which allow and attacker to force the name of the session file).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .