PHP/Apache access/permissions? I don't know... save_session_path

ShinJii

Verified User
Joined
Mar 20, 2014
Messages
219
Hi,

I have a problem since a year... 06.2018 - after some update (?) of directadmin/packages through custombuild my script doesn't respect save_session_path - before that it was everything fine.

My script:
PHP:
session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT'] . '/tmpsessions'))); // ini_set('session.save_path, $path); also not working
// chmod of this dir is 775
//var_dump(ini_get('session.save_path')); or echo session_save_path();  shows just /home/user/tmp ? why? it's not even set in php.ini and .htaccess
ini_set('session.gc_maxlifetime', 21600); // it's working - changes value
ini_set('session.gc_probability', 1); // it's working - changes value
ini_set('session.gc_divisor', 1000); // it's working - changes value
session_name('name');
session_start();

I described all in comments above.
I think it's something with permissions? Because script was working almost 2 years... and suddenly stopped... I don't know what to do... I read literally all articles about session.save_path and nothing is working...

Weirdest thing is that was working ~2 years.... and I didn't change anything....

What permissions should have PHP(fpm)/Apache in DirectAdmin to use this variable and save sessions to any dir I set (in /home/user domains/subdomains)?
 
Last edited:
I don't see it here but what is your OS and PHP version are you on? Is all of DA and the server up to date?

what do get for

php -i | grep session.save_path
 
I don't see it here but what is your OS and PHP version are you on? Is all of DA and the server up to date?

what do get for

php -i | grep session.save_path

Hi,
Yes I have everything up to date.
CentOS 7 (newest version) + DA 1.575 + PHP 7.2 (FPM)
 
Is there possibility it has something with SElinux/policy? Sometimes I have some errors while updating that package in CentOS....
 
PHP-FPM has a directive:

Code:
php_admin_value[session.save_path] = |PHP_SESSION_SAVE_PATH|

in /usr/local/directadmin/data/templates/php-fpm.conf

which makes it impossible to override the value anywhere else, as it has a precedence above all.

You need to use DirectAdmin Web-UI (go to Custom HTTPD Configurations) and customize the value of the token |PHP_SESSION_SAVE_PATH|, add:

Code:
|?PHP_SESSION_SAVE_PATH=`HOME`/domains/`DOMAIN`/public_html/tmpsessions|
into PHP-FPM config customization text-area and save.

and by the way it is set to `HOME`/tmp by default.

p.s. Storing sessions under `HOME`/domains/`DOMAIN`/public_html/tmpsessions is rather insecure I'd rather say.
 
Thanks dude! By the way - why it's insecure? I think there's less probability in this case to hijack session from other domain/subdomain?
 
Hmmm...but why I can't change this value through script? 1 year ago I could...

EDIT: Even if I do |?PHP_SESSION_SAVE_PATH=""| there's still home/user/tmp ... why? if that's empty...
 
Last edited:
Thanks dude! By the way - why it's insecure? I think there's less probability in this case to hijack session from other domain/subdomain?

It is insecure because it is within the public_html directory that is your Document Root. Therefore anyone can access the session files by going to http://<yourdomain>/tmpsessions

Session files should be stored outside your document root. You should consider putting it at the same directory level as the public_html directory, i.e. /home/<owner>/domains/<domainname>/tmpsessions that way it is ouside your document root and is at the same level as your domain logs, private html directory, etc.
 
It is insecure because it is within the public_html directory that is your Document Root. Therefore anyone can access the session files by going to http://<yourdomain>/tmpsessions

Session files should be stored outside your document root. You should consider putting it at the same directory level as the public_html directory, i.e. /home/<owner>/domains/<domainname>/tmpsessions that way it is ouside your document root and is at the same level as your domain logs, private html directory, etc.

Hmmmm... you're right... I didn't think about that :eek: thanks!
 
Back
Top