Problemas con PHP 5.3 y la carpeta de sesiones

81

Recientemente actualicé a PHP 5.3 y desde entonces recibo mensajes de error (esporádicos) que indican que Apache (o puede ser el limpiador de los archivos de sesión) no tiene permisos para la carpeta donde se almacenan las sesiones.
Esto sucede al azar y no se puede reproducir con pasos exactos, lo que me llevó a suponer que es el limpiador de sesiones.
¿Alguien tiene alguna experiencia con tales errores?

El mensaje de error (que se dispara en la session_start()línea) es:

ps_files_cleanup_dir: opendir (/ var / lib / php5) falló: Permiso denegado.

ls -ltr en el directorio de la sesión da:

drwx-wx-wt  2 root          root          4096 2010-05-25 12:39 php5

Dentro de este directorio, veo archivos de sesión propiedad de www-data, que es mi Apache, y la aplicación funciona bien. Lo que me hace preguntarme, ¿bajo qué usuario se ejecuta la sesión GC?

php session Itay Moav -Malimovka
fuente
Lo hice, pero no en 5.3. Resultó ser un error de permisos que se había filtrado a la ruta de guardado de la sesión. ¿Supongo que ha comprobado los permisos?
Jarrod Nettles
@Jarrod Veo que www-data puede leer y escribir en esa carpeta (que tiene w & r para todos en este momento, usuario, grupo y mundo). ¿Debería marcar otra cosa?
Itay Moav -Malimovka
Supongo que la razón por la que sucede esporádicamente es que el error ocurre cuando se ejecuta el recolector de basura de la sesión, que creo que de manera predeterminada tiene un 1% de probabilidad de ejecutarse por inicialización de sesión. ¿Ha realizado algún cambio en php.ini con respecto a las sesiones? ¿Qué hay fuera del valor predeterminado aquí? Verifique el propietario de la carpeta de la sesión, después de eso estoy perdido sin ver el .ini o errores.
Jarrod Nettles
El propietario es root, las sesiones son creadas por www-data, todos tienen acceso a esta carpeta. Revisaré los ajustes de ini uno por uno, buscaré algo sospechoso.
Itay Moav -Malimovka
ps_files_cleanup_dir: opendir (/ var / lib / php5) falló: Permiso denegado (
Itay Moav -Malimovka

Respuestas:

121

La solución: en tu php.iniconjunto session.gc_probabilitypara0

La causa creo que encontré la respuesta aquí http://somethingemporium.com/2007/06/obscure-error-with-php5-on-debian-ubuntu-session-phpini-garbage

Esencialmente, la recolección de basura está configurada para ser realizada por trabajos cron en algunos sistemas (es decir, Ubuntu / Debian). Algunos ejecutables de php ini como php-cli también intentan recolectar basura y eso da como resultado el error que tienes.

Diwant Vaidya
fuente
6
También estoy experimentando este problema en Ubuntu 10.04, pero al verificar el php.ini que encontré session.gc_probabilityya configurado 0.
Jonathan
5
@Jonathan - Probablemente encontrará que su aplicación está configurando el valor entonces.
SynackSA
3
@SynackSA Por extraño que parezca, es cuando creo un archivo php.ini personalizado y específico del sitio, es entonces cuando se session.gc_probabilityactiva el 1. ¡Esto sucedió incluso cuando no hay ninguna configuración en el archivo php.ini en absoluto ! Estoy ejecutando suphp en Ubuntu, Apache 2.2. Me pregunto si eso es algún tipo de error. De todos modos, agregar session.gc_probability = 0a mi archivo php.ini personalizado y específico del sitio parece resolver el problema.
Jonathan
2
@Jonathan Esa es la forma en que se supone que funciona, ya que el valor predeterminado es 1
ROunofF
2
Esto deshabilita la recolección de basura de la sesión. Probablemente debería comprobar si realmente hay un cron limpiando sus sesiones.
hansgoed
23

Este parece ser un error típico en los servidores de Ubuntu (estoy usando Lucid LTS). Los permisos predeterminados del directorio / var / lib / php5 existen

drwx-wx-wt  2 root     root     4096 2011-11-04 02:09 php5

por lo que el servidor web puede escribirlo pero no leerlo, supongo que eso explica los errores.

Como Ubuntu tiene su propia limpieza de basura a través de cron ( /etc/cron.d/php5), probablemente sea mejor deshabilitar la recolección de basura de php como sugirió Diwant Vaidya.

session.gc_probability = 0

En realidad, hay una razón por la que la carpeta de sesión no debería ser legible para todo el mundo, como dice el Manual de PHP :

Si deja este conjunto en un directorio legible en todo el mundo, como / tmp (el predeterminado), otros usuarios del servidor pueden secuestrar sesiones obteniendo la lista de archivos en ese directorio.

Marie Fischer
fuente
2

La solución que uso actualmente (que no estoy seguro de que sea la correcta) es ceder la propiedad de la carpeta de sesión al usuario de Apache (www-data en mi caso).

Itay Moav -Malimovka
fuente
2
Como Marie mencionó anteriormente, eso puede crear un problema de seguridad para cualquier servidor de producción.
Kzqai
2
Hace tiempo que implementé la solución correcta :-) Pero, el problema de seguridad está principalmente en servidores compartidos
Itay Moav -Malimovka
1
La limpieza de @pike Session es manejada por php cli a través de CRON
Itay Moav -Malimovka
1

Este problema me ha estado molestando por un tiempo. Cambié el valor como se sugiere en php.ini y el problema siguió ocurriendo. Encontré el mismo valor de configuración en mi index.php y también en private / Zend / session.php. Por lo tanto, vale la pena investigar un poco más si el problema persiste. Espero que esto sea útil para alguien.

ChrisFNZ
fuente