¿Qué permisos / propiedad establecer en la carpeta de sesiones de PHP cuando se ejecuta FastCGI / PHP-FPM (como usuario "nobody")?


17

Tengo problemas para ejecutar una serie de scripts porque PHP-FPM no puede escribir en mi carpeta de sesión:

"2009/10/01 23:54:07 [error] 17830 # 0: * 24 FastCGI enviado en stderr:" Advertencia PHP:
    Desconocido: abierto (/ var / lib / php / session / sess_cskfq4godj4ka2a637i5lq41o5, O_RDWR)
    falló: Permiso denegado (13) en Desconocido en la línea 0
Advertencia de PHP: Desconocido: Error al escribir los datos de la sesión (archivos). Por favor verificar
    que la configuración actual de session.save_path es correcta
    (/ var / lib / php / session) en Desconocido en la línea 0 "mientras lee en sentido ascendente"

Obviamente este es un problema de permiso; El propietario / grupo de mi carpeta de sesión es el usuario del servidor web, NGINX. PHP-FPM se ejecuta como nobodysi, y por lo tanto, agregarlo al grupo nginx no es tan trivial.

Una solución temporal es establecer los permisos de /var/lib/php/sessionto 777, aunque tengo la sensación de que esa no es la "mejor práctica".

¿Cuál es la mejor práctica cuando necesita asignar un acceso de escritura de daemon a una carpeta, pero se ejecuta como nobody?

Respuestas:


24

Los permisos correctos para nosotros donde

chown -R nobody:nogroup /var/lib/php/session

como se php-cgiejecuta como nobody, aunque NGinx se ejecuta como usuarionginx


En mi caso no se trataba de propiedad / permisos. Quite el "3;" from session.save_path = "3; / var / lib / php / sessions"
John Doe

1
Me sale el siguiente error: Grupo no válido << nadie: nogroup >> :(
Pathros

pude ver cuál es mi nobodyusuario que ejecuta php con esta línea de código: <?php echo exec('whoami'); ?>(en mi caso, www-data) y después de eso fue simple como acabo de escribir, chown -R www-data:www-data /var/lib/php/sessionseste es un resultado de google subestimado, ya que fue la única respuesta que ayudó yo después de horas de búsqueda! ¡Gracias!
Dimitar

9

Si usa nginx , podría encontrarse con esto cuando ejecute una actualización del sistema.

A veces, cuando actualiza el sistema, el grupo de /var/lib/php/sessionse cambia a apache.

Intente ejecutar en sudo chgrp nginx /var/lib/php/*lugar de establecer permisos en 777, que es una mala práctica.

Eso funcionó para mí al menos.


1
Esto debe marcarse como respuesta aceptada.
Yuda Prawira

3

Utilice la directiva /etc/php.ini session.save_path .

Una solución temporal es establecer los permisos de / var / lib / php / session en 777, aunque tengo la sensación de que esa no es la "mejor práctica".

"Si deja este conjunto en un directorio legible a nivel mundial, otros usuarios en el servidor podrán secuestrar sesiones obteniendo la lista de archivos en ese directorio".


Lo siento, creo que puede no haber sido claro: session.save_path ya está configurado en / var / lib / php / session. El problema es que no puedo determinar qué permisos y propiedad asignar al directorio de ruta de la sesión para permitir que PHP-FPM escriba en él, así como mantenerlo a salvo. Tener el directorio configurado como propietario / grupo "nginx" (El servidor web que estoy ejecutando) y los permisos 755 no parecen ser el truco
Profesor Frink

44
1. Uso mismo usuario: Grupo de Nginx y php-FPM (ya sea a través nginx.confo php-fpm.conf), para que pueda mantener este directorio 700. 2. Uso chown -R nginx:nobody /var/lib/php/session && chmod -R 770 /var/lib/php/sessionasí que creo que tanto nginx y php-FPM pueden usarlo
SaveTheRbtz

2
Puedo confirmar que usar nginx: nobody (o nginx: nogroup en algunas circunstancias) funciona. Sin embargo, si es posible, me inclinaría hacia la opción 1 de SaveTheRbtz.
Michael Johnson el

3

Tuve que crear una carpeta con derechos 0700 en / var / lib / php / session para cada grupo php-fpm.

El propietario de esta carpeta es el usuario y el grupo del grupo php-fpm.

Y / var / lib / php / session ahora 0777.

Creo que este método es más seguro. Solo el usuario del grupo php-fpm verá estas sesiones.


1

Tuve el mismo problema y lo resolví. Fui a /tmp(ahí es donde están mis archivos ses_ *) y los eliminé todos. Después de eso todo estuvo bien.

Tan cerca como pude ver, el sistema estaba tratando de escribir en viejos archivos bloqueados.

El problema ocurrió después de que estaba jugando php.ini. Perdí un par de años de mi vida, pero finalmente encontré la solución.


1

La forma correcta debería ser cambiar la propiedad de la carpeta de sesión a nginx. Sin embargo, PHP-FPM no se ejecuta utilizando el usuario nginx de forma predeterminada. Utiliza apache por defecto.

Dicho esto, debe cambiar el usuario que usa PHP-FPM mediante la edición /etc/php-fpm.d/www.conf.

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
; RPM: apache Choosed to be able to access some dir as httpd
user = nginx
; RPM: Keep a group allowed to write in log dir.
group = nginx

Reinicie PHP-FPM y debería estar listo para comenzar.

service php-fpm restart


La ubicación de la ruta de sesión PHP se puede encontrar en /etc/php.inidebajo session.save_path. /var/lib/php/sessiones el predeterminado

Comando para actualizar la propiedad y el grupo de la carpeta de sesión php

chown -R nginx:nginx /var/lib/php/session

Y debería ser bueno para ir incluso con chmod de 700.


1

El directorio / var / lib / php / sessions debe tener permisos de bits fijos.

sudo chmod 1773 /var/lib/php/sessions

ls -al /var/lib/php/
drwxr-xr-x  4 root root   .
drwxr-xr-x 51 root root   ..
drwxr-xr-x  3 root root   modules
drwx-wx-wt  2 root root   sessions

0

Basado en la respuesta de @Judder , para que funcione tuve que agregar el siguiente comando para dar permisos de lectura y escritura a nadie y nogroup :

chown -R nobody:nogroup /var/lib/php/session

sudo chmod -R ug+rw /var/lib/php/sessions

chmod cambiará los permisos en la carpeta dada
-R aplicará los mismos permisos a las carpetas y archivos creados dentro de la carpeta dada
u para el usuario
g para el grupo
r para el permiso de lectura
w para el permiso de escritura

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.