Configuring Session Handler path for open_basedir

Using Concrete / Help
1

I am deploying 9.1.3 on a new server that is out of my partially out of my control. The hosting provider has open_basedir configured and for the most part there are no problems with any of the other tools I’ve deployed onto their servers. Uniquely Concrete5 seems to be unhappy even when I switch the Session Handler to be “Database” with the open_basedir. The operator says that any tool that is configured to use a customer session handler should also provide mechanisms to specify the path. But I can’t seem to find an option to do that in the web based installation. Is there a way around this issue? This is the error that I am getting:

is_dir(): open_basedir restriction in effect. File(/home/system/var/lib/php/sessions) is not within the allowed path(s): (/tmp:/var/tmp:/usr/bin:/home/Gorf).

Trace:
#0 [internal function]: Whoops\Run->handleError(2, 'is_dir(): open_...', '/home/Gorf/swee...', 50) #1 /home/Gorf/[snipped for privacy]/dev/html/concrete/src/Session/Storage/Handler/NativeFileSessionHandler.php(50): is_dir('/home/system/va...') #2 [internal function]:
Concrete\Core\Session\Storage\Handler\NativeFileSessionHandler->__construct('/home/system/va...') #3
2

Anyone have any feedback here?

3

Hi @Gorf - sorry haven’t run into this in my travels - strange to have restrictions on something like that by your hosting provider.

4

open_basedir is an extremely common security control in a multi-user hosting environment to prevent malicious code from one customer doing lateral reconnaissance of other customers or the hosted operating system itself.

5

Here are a couple links that might be helpful:

And more recent comments on this Github issue:

Otherwise might be something worth opening a new issue about

6
  1. Find your path to your site: echo $_SERVER['DOCUMENT_ROOT'];
  2. when installing, change in concrete/config/concrete.php, in the session part: 'save_path' => null, to 'save_path' => '/your_path/application/files/tmp',

In an existing site, add a file concrete.php (if not already exists) in /application/config/ and add:

<?php return [ 'session' => [ 'save_path' => '/your_path/application/files/tmp', ] ];
7

It’s not a good idea to store session files in a publicly accessible directory (hackers could find a way to download them and try to do harmful things).
If you really have to, you should “protect” them adding an nginx or apache rule that disable access to them.

2 Likes
8

Thank you, I’m now pointing to a folder above the web root folder.

1 Like
9

With apologies for bumping this topic, I think it’s relevant to add my experience for others who may encounter this.

I had a frustrating experience trying to solve open_basedir problems. I’m completely new to Concrete, and every time I experienced an error I had to go and delete the database in order to restart the install and try a new solution. I eventually figured out that my hosting provider had configured a random, unusable “session.save_path” folder in php settings. The solution was to identify (as @nickratering did) a folder above web root and put that into a concrete.php file as described. In my case my web root is at /home/[xxx]/example.com/private_html/ and I have selected to use /home/[xxx]/tmp as my session.save_path.

For reference, the error I was getting was

is_dir(): open_basedir restriction in effect. File(/opt/alt/php74/var/lib/php/session) is not within the allowed path(s): (/home/[xxx]/:/tmp:/var/tmp:/opt/alt/php81/usr/share/pear/:/dev/urandom:/usr/local/lib/php/:/usr/local/php81/lib/php/).

My hosting provider had set session.save_path to /opt/alt/php74/var/lib/php/session but despite me trying to use their hosting panel to add that folder to the open_basedir php variable (so that the webserver has permission to run, it didn’t seem to solve the problem. Much better to use a folder within my home directory for this rather than a global folder, I guess.

BTW, I first developed insight into this problem by setting session.save_path to a folder I didn’t have permission to write in, and my error changed from an open_basedir one to a write permission error.

I note that in this post another user solved the open_basedir error by using their hosting control panel to change the session (“upload_tmp_dir”) folder location - although I think that solution encounters the security issue mentioned above, that it puts tmp files into publicly accessible folders (in WEBSPACEROOT). Request failed: unable to verify support for request URLs - Installation - Concrete CMS

I’m not sure how common this open_basedir install issue is, but I wonder if it might be worth putting it into the install test page or into the install instructions.

1 Like