Cannot run concrete5 because open_basedir restriction

[HeikkiYlipaavalniemi]

When trying to run concrete5 5.7.4.2 in our new host, I get the following error:

is_dir(): open_basedir restriction in effect. File(/var/lib/php) is not within the allowed path(s): (/home/user/:/tmp:/var/tmp:/usr/local/lib/php/:/usr/local/php55/lib/php/)

I asked about this from our host, and they said that this is a bug in concrete5 itself and they cannot fix it without compromising the servers security.

Installation was fine on other server but the new server seems to have stricter open_basedir settings.

[HeikkiYlipaavalniemi]

According to the host, they were able to do a clean install even with 5.7.3.1. But transferring an existing installation does not work.

Might it be that the old server settings are stored somewhere and they are conflicting with the new server?

[mlocati]

There are 183 places where is_dir is called: finding the one that gives you this error is quite hard without more details: when does it occur?
To retrieve the full error details you could temporarily change the file application/config/generated_overrides/concrete.php.
You should have something like this in that file:

<?php

/**
 * -----------------------------------------------------------------------------
 * Generated ...
 *
 * @item      ...
 * @group     concrete
 * @namespace null
 * -----------------------------------------------------------------------------
 */
return array(
    'site' => '...',
    'version_installed' => '...',
    [...]
);

You should add these lines just after return array(:

    'debug' => array(
        'detail' => 'debug',
        'display_errors' => true
    ),

Doing so, you should see the full log of the error, so that we can see where this error occurs.

[HeikkiYlipaavalniemi]

It was actually coming from all addresses which I tried to access. But adding that debug line gave more information:

/public_html/concrete/vendor/symfony/http-foundation/Symfony/Component/HttpFoundation/Session/Storage/Handler/NativeFileSessionHandler.php

throw new \InvalidArgumentException(sprintf('Invalid argument $savePath '%s'', $savePath));
}

        // characters after last ';' are the path
        $baseDir = ltrim(strrchr($savePath, ';'), ';');
    }

    if ($baseDir && !is_dir($baseDir)) {
        mkdir($baseDir, 0777, true);
    }

[HeikkiYlipaavalniemi]

Possible the same issue:
https://www.concrete5.org/developers/bugs/5-7-4-2/installing-with-open_basedir-still-fails/

[mlocati]

Could you see the value of the session.save_path configuration of PHP?

The simplest way to do this is to temporarily change the file index.php by adding these two lines right after <?php:

var_dump(ini_get('session.save_path'));
die();

[HeikkiYlipaavalniemi]

string(12) "/var/lib/php"

[mlocati]

I see these options to solve the problem:

1. You (or your provider) change the value if that configuration parameter to specify a directory that's accessible and writable by the php installation
2. You choose to save the session data in the database (see https://www.concrete5.org/documentation/how-tos/developers/enable-database-based-sessions-on-5.7/ )

@aembler What about adding a new configuration parameter to change the default path where the session files are saved? It's quite simple, just update the initialization of NativeFileSessionHandler

[HeikkiYlipaavalniemi]

Thanks for the quick help.

Changing sessions to database fixed the problem.

Seems there is still something funky with the new server because I get often when opening pages:
No data received

ERR_EMPTY_RESPONSE

Waiting for a moment (1-2 seconds) and the page will then open fine.

Will have to consult the host about that one.

[HeikkiYlipaavalniemi]

Opening a normal HTML page works without problems in the host. Seems like its just concrete5 which is not sending data at first.

Do you have any pointers how this could be debugged?

[KorvinSzanto]

In the future, lets suggest people add to /application/config/concrete.php
and not the generated override file so that people don't get confused.
On Tue, Oct 27, 2015 at 8:05 AM Andrew Embler notifications@github.com
wrote:

Closed #2579 #2579.

—
Reply to this email directly or view it on GitHub
#2579 (comment).

[mlocati]

You should be able to configure where session files are stored by using the concrete.session.save_path configuration option.
You can set it with the command line (or with Handyman 😉)

[Hypocrite]

Seems really weird. After changing sessions to database, I can login with my own credentials but another user is having trouble logging in. She has tried on several computers and also I tried with her credentials and we both get error 500 for Access denied.

[Hypocrite]

I was able to fix the problem by reverting back to PHP 5.6 and using files to save sessions.

But with PHP 7 and database storage the user gets logged out immediately after clicking some link.

I checked the Sessions table in database and it seems that sessions are generated but they are just not valid.

Example sessionValue:

_sf2_attributes|a:3:{s:7:"uGroups";a:1:{i:1;s:1:"1";}s:14:"accessEntities";a:1:{i:0;O:50:"Concrete\Core\Permission\Access\Entity\GroupEntity":6:{s:8:"�*�group";O:30:"Concrete\Core\User\Group\Group":22:{s:4:"ctID";N;s:13:"permissionSet";N;s:43:"�Concrete\Core\User\Group\Group�permissions";a:0:{}s:5:"error";s:0:"";s:3:"gID";s:1:"1";s:5:"gName";s:5:"Guest";s:12:"gDescription";s:62:"The guest group represents unregistered visitors to your site.";s:24:"gUserExpirationIsEnabled";s:1:"0";s:21:"gUserExpirationMethod";N;s:26:"gUserExpirationSetDateTime";N;s:23:"gUserExpirationInterval";s:1:"0";s:21:"gUserExpirationAction";N;s:8:"gIsBadge";s:1:"0";s:9:"gBadgeFID";s:1:"0";s:17:"gBadgeDescription";N;s:25:"gBadgeCommunityPointValue";s:1:"0";s:12:"gIsAutomated";s:1:"0";s:26:"gCheckAutomationOnRegister";s:1:"0";s:23:"gCheckAutomationOnLogin";s:1:"0";s:24:"gCheckAutomationOnJobRun";s:1:"0";s:5:"gPath";s:6:"/Guest";s:5:"pkgID";s:1:"0";}s:5:"error";s:0:"";s:5:"petID";s:1:"1";s:4:"peID";s:1:"2";s:9:"petHandle";s:5:"group";s:5:"label";s:5:"Guest";}}s:21:"accessEntitiesUpdated";i:1518199615;}_sf2_flashes|a:0:{}_sf2_meta|a:3:{s:1:"u";i:1518199615;s:1:"c";i:1518199613;s:1:"l";s:1:"0";}

[Hypocrite]

And sorry, I deleted the original message because I thought I solved the problem before.

So the original problem was that our host changed the PHP 7 settings for where the sessions are stored. I then changed our settings for saving sessions to database but this lead to problems for users to login. Users were able to login but they were immediately kicked out with invalid session.

Users kept getting logged out even though they cleared temporary files, cookies, restarted browser or even used a completely different computer. And I was also getting logged out when using another users username / password with similar problems.

I also tried to define the sessions save path in concrete5.php but that did not seem to work either.

The original error went away after saving sessions to database but sessions were not working correctly anymore.

[mlocati]

If you set the concrete.session.save_path` configuration key to a writable directory and using file-based session files, what's the error message that you see?

[Hypocrite]

I think I got it working now. I changed the directory permissions and now files seem to be getting generated again and user seems to be able to login.

Still wondering what messes up with the database sessions but at least the biggest problem seems to be over.

Thanks a ton.

[Hypocrite]

Also on a sidenote.
What is the current process for deleting old session files? I think in some earlier version of concrete5 we had the problem that the session files started to take a lot of space. Is there some cleanup job and does it work for a custom path? Or should I setup some cronjob for this?