2010-05-28 28 views
25

Je travaille actuellement sur une nouvelle application en utilisant (entre autres) Zend_Auth mais, pour une raison quelconque, ce message d'erreur montre à tout endroit tout à fait au hasard (ou alors il coutures)Zend_Session/Zend_Auth lance le message d'erreur ps_files_cleanup_dir: opendir (/ var/lib/php5) a échoué: Permission denied (13)

Zend_Session::start() - /home/hannes/workspace/develop/library/Zend/Session.php(Line:480): erreur # 8 session_start() [function.session-start]: ps_files_cleanup_dir: opendir (/ var/lib/php5) a échoué: Permission refusée (13) tableau

  • # 0 /home/hannes/workspace/develop/library/Zend/Session/Namespace.php(143): Zend_Session :: start (true)
  • # 1/home/hannes/espace de travail/développement/bibliothèque/Zend/Auth/Storage/Session.php (87): Zend_Session_Namespace -> __ construct ('Zend_Auth')
  • # 2 /home/hannes/workspace/develop/library/Zend/Auth.php(91): Zend_Auth_Storage_Session-> __construct()
  • # 3 /home/hannes/workspace/develop/library/Zend/Auth.php(141): Zend_Auth-> getStorage()
  • # 4/home/hannes/espace de travail/développement/xxxxxxx/application/controllers/AdminController.php (10): Zend_Auth-> hasIdentity()
  • # 5 /home/hannes/workspace/develop/library/Zend/Controller/Action.php(133): AdminController-> init()
  • # 6/home/hannes/workspace/develop/bibliothèque/Zend/Contrôleur /Dispatcher/Standard.php(262): Zend_Controller_Action -> __ construct (Objet (Zend_Controller_Request_Http), Objet (Zend_Controller_Response_Http), Array)
  • # 7 /home/hannes/workspace/develop/library/Zend/Controller/Front.php (954): Zend_Controller_Dispatcher_Standard-> dispatch (Object (Zend_Controller_Request_Http), objet (Zend_Controller_Response_Http))
  • # 8 /home/hannes/workspace/develop/library/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front- > dispatch()
  • # 9/maison/hanne s/espace de travail/développement/bibliothèque/Zend/Application.php (366): Zend_Application_Bootstrap_Bootstrap-> run()
  • # 10 /home/hannes/workspace/develop/xxxxxxx/public/index.php(26): Zend_Application- > run()
  • # 11 {main}

Répondre

12

Une solution est de mettre le session.save_path dans le fichier php.ini dans un répertoire inscriptible. par exemple: session.save_path = "/ tmp". La désactivation de la récupération de place dans le premier exemple n'est pas une bonne idée. Le deuxième exemple ne fonctionne pas sur Ubuntu 10.04

+0

simple et fonctionnel – Hannes

+0

excellente solution. – typeoneerror

+10

désolé, juste venu ici. C'est une mauvaise solution. Pourquoi? Parce qu'il est intendant que personne d'autre que root puisse entrer dans ce répertoire. Je pense que sur un serveur web exécutant PHP, le répertoire de session est l'un des répertoires les plus vulnérables. Supposons que vous ayez une webapp exploitable, qui vous donne un accès en lecture à/tmp, l'attaquant peut pirater n'importe quelle session qui est actuellement active uniquement en obtenant les noms de fichiers. Dieu sait quelles sont les données vulnérables dans la session elle-même. En résumé, C'EST UNE IDÉE TRÈS MAUVAISE DE METTRE LES SESSIONS SOUS/TMP. Fin de l'histoire! :) – evildead

16

Apparemment, ce problème affecte la plupart du temps (seulement?) des systèmes basés sur debian/ubuntu et a à voir avec la collecte des ordures de la session automatique.

La variable session.gc_probability a été mis à 1 dans le php.ini qui signifie qu'il y a une probabilité de 1% pour le collecteur d'ordures pour exécuter et nettoyer le répertoire/var/lib/php5 où les sessions PHP sont stocké.

Apparemment, ce dossier n'est pas accessible en écriture par www-data résultant de l'erreur mentionnée et en lançant l'exception Zend. Définir session.gc_probability à 0 a résolu le problème. Le dossier de session est nettoyé par un travail cron de toute façon, donc pas besoin que le garbage collector php fonctionne.

De http://somethingemporium.com/2007/06/obscure-error-with-php5-on-debian-ubuntu-session-phpini-garbage

+0

déjà essayé celui-là, m'a apporté de 1 échec de 20 à 20 échoue sur 20 :( – Hannes

+1

@Hannes: que vous avez fait quelque chose de mal – evildead

+0

@evildead! non ... – Hannes

5

J'ai eu ce problème avec le framework Symfony aussi, le problème est php ne pas l'autorisation dans le répertoire de stockage de session. Changez simplement le répertoire de sauvegarde de session en quelque chose d'inscriptible.Dans Zend Framework Bootstrap config ini:

resources.session.save_path = APPLICATION_PATH "/../data/session" 
11

En fait, changer le répertoire du session.save_path désactive la récupération de place. C'est pourquoi cela fonctionne maintenant pour vous. Si vous voulez la collecte des ordures, vous pouvez changer le propriétaire du répertoire d'origine à l'utilisateur php « www-data »

chown www-data/var/lib/php5

En alternative, vous pouvez écrire un script de collecte des ordures pour le nouveau répertoire.

+0

cela a fonctionné pour moi – easyrider

1

J'ai rencontré ce problème sous OS X 10.8.4 avec MAMP, en utilisant le premier Zend Framework. Le répertoire défini pour session.save_path dans php.ini par défaut est /Applications/MAMP/tmp/php. J'ai été capable de le résoudre seulement en supprimant tout dans ce répertoire.

1

Si vous utilisez PHP 7,0

sudo chown www-data:www-data /var/lib/php/sessions 
+0

Uhm, merci ... je n'ai jamais vraiment résolu ce problème, mais d'autre part - c'était il y a 7 ans: D – Hannes