Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SessionHandler::gc(): ps_files_cleanup_dir | Permission denied (13)

i have a problem with PHP7 in CentoOS (WHM/CPANEL) and Prestashop 1.7

the system gives me this messagges:

Notice on line 429 in file /home/onywf3fr9a/public_html/app/cache/dev/classes.php

[8] SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php70) failed: Permission denied (13)

like image 581
user3250372 Avatar asked Oct 31 '17 19:10

user3250372


3 Answers

I have the same issue, I changed the session.save_pathphp.ini to "/tmp" in my php.ini

like image 185
Sarath E Avatar answered Oct 18 '22 10:10

Sarath E


Background

This error occurs when PHP tries to garbage collect expired sessions, but the directory containing the session files is not listable (missing the r access bit) by the user PHP runs as.

This is usually a security measure against PHP session hijacking. E.g. Debian sets the permissions for the session directory to drwx-wx-wt. These permissions allow anyone to create sessions and the user who created the session may read it again if they knows the file name (session id), but only root can get a list of all active sessions.

Distributions with this configuration normally also set up a cronjob or timer that regularly cleans up the sessions and disable the native garbage collection in php.ini: session.gc_probability = 0.

Possible Causes

  1. You or someone else modified the php.ini and changed session.gc_probability to a value other than 0.
  2. A PHP script uses ini_set() to modify session.gc_probability at runtime. Some PHP frameworks are prone to this. E.g. Symfony always sets session.gc_probability to 1 if not configured otherwise.
  3. You or someone else managing the server botched up the session directory permissions on a system that doesn't use a cronjob or timer to cleanup expired sessions.

Solutions

  1. Change session.gc_probability in php.ini to 0 after verifying that your installation uses a cronjob/timer for session cleanup.

    • CPanel uses /usr/local/cpanel/scripts/clean_user_php_sessions to remove expired sessions, so all CPanel installations use a cronjob.
    • Debian, Ubuntu and Linux Mint use a systemd timer phpsessionclean.timer for session cleanup.
  2. Prevent the web application from overriding session.gc_probability. For Symfony based applications this can be done by modifying config/packages/framework.yaml:

    framework:
        session:
            gc_probability: null
    
  3. If your system really uses the native session garbage collection instead of a cronjob or timer, change the permissions of the session folder to allow listing for the user running PHP:

    # Check beforehand which group php-fpm runs as. Here I assume www-data:
    chgrp www-data /var/cpanel/php/sessions/ea-php70
    chmod g+r /var/cpanel/php/sessions/ea-php70
    

    Security notice: Changing the permissions allows any PHP script to enumerate all active session ids and potentially access all sessions. Only do this if you are sure the solutions above aren't applicable!

  4. (Potentially dangerous) Change session.save_path to /tmp or a similar directory that PHP can access for reading and writing.

    Security notice: Changing the session save path to a world-readable directory allows any program and any PHP script to enumerate all active session ids and potentially access all sessions. Only do this if you are sure the solutions above aren't applicable!

like image 15
cg909 Avatar answered Oct 18 '22 09:10

cg909


I cleared cache and problem has been solved :)

like image 5
William Rossier Avatar answered Oct 18 '22 10:10

William Rossier