php - directories - laravel storage permissions

Cómo configurar permisos de archivo para Laravel 5(y otros)

Question

Estoy usando el servidor web Apache que tiene el propietario configurado en _www:_www . Nunca sé cuál es la mejor práctica con los permisos de archivos, por ejemplo, cuando creo un nuevo proyecto de Laravel 5.

Laravel 5 requiere /storage carpeta de /storage para poder escribirse. Encontré muchos enfoques diferentes para que funcione y generalmente termino haciéndolo 777 chmod de forma recursiva. Sin embargo, sé que no es la mejor idea.

El documento oficial dice:

Laravel puede requerir que se configuren algunos permisos: las carpetas dentro del storage y el vendor requieren acceso de escritura por parte del servidor web.

¿Significa que el servidor web también necesita acceso al storage y a vendor carpetas de los vendor o solo a sus contenidos actuales?

Supongo que lo que es mucho mejor es cambiar el propietario en lugar de los permisos. Cambié todos los permisos de archivos de Laravel de forma recursiva a _www:_www y eso hizo que el sitio funcionara correctamente, como si cambiara chmod a 777 . El problema es que ahora mi editor de texto me pide una contraseña cada vez que quiero guardar un archivo y ocurre lo mismo si intento cambiar algo en Finder, como por ejemplo copiar un archivo.

¿Cuál es el enfoque correcto para resolver estos problemas?

1. Cambiar chmod
2. Cambie el propietario de los archivos para que coincida con los del servidor web y quizás configure el editor de texto (¿y Finder?) Para omitir la solicitud de contraseña o hacer que usen sudo
3. Cambie el propietario del servidor web para que coincida con el usuario del sistema operativo (no sé las consecuencias)
4. Algo más

Answer 1

Añadir a composer.json

"scripts": {
"post-install-cmd": [
"chgrp -R www-data storage bootstrap/cache",
"chmod -R ug+rwx storage bootstrap/cache"
]
}

Después de composer install

Answer 2

Los documentos de Laravel 5.4 dicen:

Después de instalar Laravel, es posible que deba configurar algunos permisos. Los directorios dentro del storage y los directorios bootstrap/cache deben ser editables por su servidor web o Laravel no se ejecutará. Si está utilizando la máquina virtual Homestead, estos permisos ya deberían estar configurados.

Hay muchas respuestas en esta página que mencionan el uso de permisos 777 . No hagas eso. Te expondrías a los hackers.

En su lugar, siga las sugerencias de otros sobre cómo establecer permisos de 755 (o más restrictivos). Es posible que necesite averiguar a qué usuario se está ejecutando su aplicación ejecutando whoami en el terminal y luego cambiar la propiedad de ciertos directorios usando chown -R .

Si no tiene permiso para usar sudo ya que muchas otras respuestas requieren ...

Su servidor es probablemente un host compartido como Cloudways.

(En mi caso, había clonado mi aplicación Laravel en un segundo servidor mío de Cloudways, y no estaba funcionando completamente porque los permisos de los directorios de storage y bootstrap/cache estaban en mal estado).

Necesitaba usar:

Cloudways Platform > Server > Application Settings > Reset Permission

Entonces podría ejecutar php artisan cache:clear en la terminal.

Answer 3

Cambie los permisos para su carpeta de proyecto para habilitar la lectura / escritura / ejecución para cualquier usuario dentro del grupo que posee el directorio (que en su caso es _www ):

chmod -R 775 /path/to/your/project

Luego agregue su nombre de usuario OS X al grupo _www para permitirle acceder al directorio:

sudo dseditgroup -o edit -a yourusername -t user _www

Answer 4

Como ya publicado

Todo lo que necesita hacer es dar la propiedad de las carpetas a Apache:

pero agregué -R para el comando chown : sudo chown -R www-data:www-data /path/to/your/project/vendor sudo chown -R www-data:www-data /path/to/your/project/storage

Answer 5

Decidí escribir mi propio guión para aliviar un poco el dolor de configurar proyectos.

Ejecute lo siguiente dentro de la raíz del proyecto:

wget -qO- https://raw.githubusercontent.com/defaye/bootstrap-laravel/master/bootstrap.sh | sh

Espera a que se complete el arranque y listo.

Revise el script antes de usarlo.

Answer 6

Encontré una solución aún mejor para esto. Se debe a que php se ejecuta como otro usuario de forma predeterminada.

para arreglar esto

sudo nano /etc/php/7.0/fpm/pool.d/www.conf

luego edite el user = "put user that owns the directories" group = "put user that owns the directories"

entonces:

sudo systemctl reload php7.0-fpm

Answer 7

He instalado laravel en la instancia EC2 y he pasado 3 días para corregir el error de permiso y finalmente lo solucioné. Así que quiero compartir esta experiencia con otra.

1. problema del usuario Cuando inicié sesión en la instancia ec2, mi nombre de usuario es ec2-user y usergroup es ec2-user. Y el sitio web funciona con httpd user: apache: apache, por lo que debemos establecer el permiso para apache.

2. permiso de carpeta y archivo A. estructura de carpeta primero, debe asegurarse de tener dicha estructura de carpeta como esta en almacenamiento

   almacenamiento

   • marco de referencia
     • cache
     • sesiones
     • puntos de vista
   • registros La estructura de la carpeta puede ser diferente según la versión laravel que utilice. mi versión laravel es 5.2 y puede encontrar la estructura adecuada según su versión.

B. permiso Al principio, veo las instrucciones para configurar 777 en almacenamiento para eliminar file_put_contents: error al abrir la secuencia de error. Así que configuré el permiso 777 para el almacenamiento chmod -R 777 storage Pero el error no se solucionó. aquí, debe considerar uno: quién escribe archivos en el almacenamiento / sesiones y vistas. Eso no es ec2-user, sino apache. Si claro. El usuario "apache" escribe el archivo (archivo de sesión, archivo de vista compilado) en la carpeta de sesión y vista. Por lo tanto, debe otorgarle a Apache permiso para escribir en esta carpeta. Por defecto: SELinux dice que la carpeta / var / www debe ser de solo lectura por el demonio apache.

Entonces, para esto, podemos establecer el selinux como 0: setenforce 0

Esto puede resolver el problema temporalmente, pero esto hace que mysql no funcione. entonces esta no es una buena solución.

Puede establecer un contexto de lectura y escritura en la carpeta de almacenamiento con: (recuerde setenforce 1 para probarlo)

chcon -Rt httpd_sys_content_rw_t storage/

Entonces su problema será solucionado.

3. y no olvides esta actualización del compositor php artisan cache: clear

   Estos comandos serán útiles después o antes.

   Espero que te ahorres tiempo. Buena suerte. Hacken

Answer 8

La mayoría de las carpetas deben ser normales "755" y archivos, "644"

Laravel requiere que algunas carpetas sean grabables para el usuario del servidor web. Puede usar este comando en sistemas operativos basados ​​en Unix.

sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache

Answer 9

La solución publicada por bgles es acertada para mí en términos de establecer correctamente los permisos inicialmente (uso el segundo método), pero aún tiene problemas potenciales para Laravel.

Por defecto, Apache creará archivos con 644 permisos. Así que eso es prácticamente cualquier cosa en el almacenamiento. Entonces, si elimina el contenido de almacenamiento / marco / vistas, luego acceda a una página a través de Apache, encontrará que la vista en caché se ha creado como:

-rw-r--r-- 1 www-data www-data 1005 Dec 6 09:40 969370d7664df9c5206b90cd7c2c79c2

Si ejecuta "servicio artesanal" y accede a una página diferente, obtendrá diferentes permisos porque CLI PHP se comporta de manera diferente a Apache:

-rw-rw-r-- 1 user www-data 16191 Dec 6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e

En sí mismo, esto no es gran cosa, ya que no harás nada de esto en producción. Pero si Apache crea un archivo que posteriormente debe ser escrito por el usuario, fallará. Y esto puede aplicarse a los archivos de caché, las vistas en caché y los registros cuando se implementa utilizando un usuario registrado y un artesano. Un ejemplo fácil es "caché artesanal: claro" que no podrá eliminar los archivos de caché que son www-data: www-data 644.

Esto se puede mitigar parcialmente mediante la ejecución de comandos artesanales como www-data, por lo que estará haciendo / scripting todo como:

sudo -u www-data php artisan cache:clear

O evitará el tedio de esto y agregará esto a sus .bash_aliases:

alias art=''sudo -u www-data php artisan''

Esto es lo suficientemente bueno y no afecta la seguridad de ninguna manera. Pero en las máquinas de desarrollo, ejecutar scripts de prueba y saneamiento hace que esto sea difícil de manejar, a menos que desee configurar alias para usar ''sudo -u www-data'' para ejecutar phpunit y todo lo demás con lo que verifica sus compilaciones que podrían crear archivos.

La solución es seguir la segunda parte de los consejos de Bgles y agregar lo siguiente a / etc / apache2 / envvars, y reiniciar (no recargar) Apache:

umask 002

Esto obligará a Apache a crear archivos como 664 por defecto. En sí mismo, esto puede presentar un riesgo de seguridad. Sin embargo, en los entornos Laravel que se tratan principalmente aquí (Homestead, Vagrant, Ubuntu), el servidor web se ejecuta como usuario www-data en el grupo www-data. Por lo tanto, si no permite arbitrariamente que los usuarios se unan al grupo www-data, no debería haber ningún riesgo adicional. Si alguien logra salir del servidor web, tiene un nivel de acceso a datos www de todos modos, por lo que no se pierde nada (aunque esa no es la mejor actitud para tener que ver con la seguridad). Entonces, en la producción es relativamente seguro, y en una máquina de desarrollo de un solo usuario, simplemente no es un problema.

En última instancia, como su usuario está en el grupo www-data, y todos los directorios que contienen estos archivos son g + s (el archivo siempre se crea bajo el grupo del directorio principal), todo lo creado por el usuario o por www-data será r / w para el otro.

Y ese es el objetivo aquí.

editar

Al investigar el enfoque anterior para establecer más los permisos, todavía se ve lo suficientemente bueno, pero algunos ajustes pueden ayudar:

Por defecto, los directorios son 775 y los archivos son 664 y todos los archivos tienen el propietario y el grupo del usuario que acaba de instalar el marco. Entonces supongamos que comenzamos desde ese punto.

cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./

Lo primero que hacemos es bloquear el acceso a todos los demás y hacer que el grupo sea www-data. Solo el propietario y los miembros de www-data pueden acceder al directorio.

sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache

Para permitir que el servidor web cree services.json y compiled.php, como lo sugiere la guía de instalación oficial de Laravel. Establecer el bit fijo del grupo significa que estos serán propiedad del creador con un grupo de datos www.

find storage -type d -exec sudo chmod 2775 {} /;
find storage -type f -exec sudo chmod 664 {} /;
sudo chgrp -R www-data storage

Hacemos lo mismo con la carpeta de almacenamiento para permitir la creación de caché, registro, sesión y visualización de archivos. Usamos find para establecer explícitamente los permisos de directorio de manera diferente para directorios y archivos. No necesitábamos hacer esto en bootstrap / cache ya que no hay (normalmente) ningún subdirectorio allí.

Es posible que deba volver a aplicar cualquier indicador ejecutable y eliminar vendor / * y reinstalar las dependencias del compositor para volver a crear enlaces para phpunit et al, por ejemplo:

chmod +x .git/hooks/*
rm vendor/*
composer install -o

Eso es. Excepto por la umask para Apache explicada anteriormente, esto es todo lo que se requiere sin hacer que todo el proyecto sea grabable por www-data, que es lo que sucede con otras soluciones. Por lo tanto, es marginalmente más seguro de esta manera, ya que un intruso que se ejecuta como www-data tiene un acceso de escritura más limitado.

fin editar

Cambios para Systemd

Esto se aplica al uso de php-fpm, pero tal vez otros también.

El servicio systemd estándar debe ser anulado, la umask configurada en el archivo override.conf y el servicio reiniciado:

sudo systemctl edit php7.0-fpm.service
Use:
[Service]
UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service

Answer 10

Los permisos para las carpetas de storage y vendor deben permanecer en 775 , por razones de seguridad obvias.

Sin embargo, tanto su computadora como su servidor Apache deben poder escribir en estas carpetas. Ej: cuando ejecuta comandos como php artisan , su computadora necesita escribir en el archivo de registros en el storage .

Todo lo que necesita hacer es dar la propiedad de las carpetas a Apache:

sudo chown -R www-data:www-data /path/to/your/project/vendor
sudo chown -R www-data:www-data /path/to/your/project/storage

Luego debe agregar su computadora (referenciada por su username de username ) al grupo al que pertenece el servidor Apache. Al igual que :

sudo usermod -a -G www-data userName

NOTA: con mayor frecuencia, groupName es www-data pero, en su caso, reemplácelo con _www

Answer 11

Nos hemos encontrado con muchos casos extremos al configurar permisos para aplicaciones Laravel. Creamos una cuenta de usuario separada ( deploy ) para poseer la carpeta de la aplicación Laravel y ejecutar los comandos de Laravel desde la CLI, y ejecutamos el servidor web en www-data . Un problema que esto causa es que los archivos de registro pueden ser propiedad de www-data o deploy , dependiendo de quién escribió primero en el archivo de registro, obviamente evitando que el otro usuario lo escriba en el futuro.

He descubierto que la única solución sana y segura es usar ACL de Linux. El objetivo de esta solución es:

1. Para permitir al usuario que posee / implementa la aplicación acceso de lectura y escritura al código de la aplicación Laravel (utilizamos un usuario llamado deploy ).
2. Para permitir al usuario de www-data acceso de lectura al código de la aplicación Laravel, pero no acceso de escritura.
3. Para evitar que otros usuarios accedan al código / datos de la aplicación Laravel.
4. Para permitir que tanto el usuario de www-data usuario de la aplicación ( deploy ) accedan a la carpeta de almacenamiento, independientemente del usuario que posea el archivo (por lo que tanto la deploy como www-data pueden escribir en el mismo archivo de registro, por ejemplo)

Logramos esto de la siguiente manera:

1. Todos los archivos dentro de la application/ carpeta se crean con la umask predeterminada de 0022 , lo que da como resultado que las carpetas tengan drwxr-xr-x y los archivos que tengan -rw-r--r-- .
2. sudo chown -R deploy:deploy application/ (o simplemente implementa tu aplicación como usuario de deploy , que es lo que hacemos).
3. chgrp www-data application/ para dar acceso al grupo www-data a la aplicación.
4. chmod 750 application/ para permitir que el usuario de deploy lea / escriba, el usuario www-data de solo lectura y elimine todos los permisos para cualquier otro usuario.
5. setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/ para establecer los permisos predeterminados en el storage/ carpeta y todas las subcarpetas. Cualquier carpeta / archivo nuevo creado en la carpeta de almacenamiento heredará estos permisos ( rwx para www-data e deploy ).
6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/ para establecer los permisos anteriores en cualquier archivo / carpeta existente.

Answer 12

Solo para decir lo obvio para cualquiera que esté viendo esta discusión ... si le das permiso a cualquiera de tus carpetas 777, estás permitiendo que CUALQUIERA lea, escriba y ejecute cualquier archivo en ese directorio ... lo que esto significa es que has dado CUALQUIERA (cualquier hacker o persona maliciosa en todo el mundo) tiene permiso para cargar CUALQUIER archivo, virus o cualquier otro archivo, y ENTONCES ejecutar ese archivo ...

SI ESTA CONFIGURANDO SUS PERMISOS DE CARPETA EN 777, HA ABIERTO SU SERVIDOR A ALGUIEN QUE PUEDA ENCONTRAR ESE DIRECTORIO. ¿¿¿Bastante claro??? :)

Básicamente, hay dos formas de configurar su propiedad y permisos. O se otorga la propiedad o hace que el servidor web sea el propietario de todos los archivos.

Servidor web como propietario (la forma en que la mayoría de la gente lo hace, y la forma del documento de Laravel):

suponiendo que www-data (podría ser otra cosa) es su usuario de servidor web.

sudo chown -R www-data:www-data /path/to/your/laravel/root/directory

si hace eso, el servidor web posee todos los archivos, y también es el grupo, y tendrá algunos problemas para cargar archivos o trabajar con archivos a través de FTP, porque su cliente FTP se registrará como usted, no como su servidor web, así que agregue su usuario al grupo de usuarios del servidor web:

sudo usermod -a -G www-data ubuntu

Por supuesto, esto supone que su servidor web se está ejecutando como www-data (el valor predeterminado de Homestead), y su usuario es ubuntu (es vagabundo si está utilizando Homestead).

Luego establece todos sus directorios en 755 y sus archivos en 644 ... SET permisos de archivo

sudo find /path/to/your/laravel/root/directory -type f -exec chmod 644 {} /;

SET permisos de directorio

sudo find /path/to/your/laravel/root/directory -type d -exec chmod 755 {} /;

Tu usuario como propietario

Prefiero poseer todos los directorios y archivos (hace que trabajar con todo sea mucho más fácil), así que hago:

sudo chown -R my-user:www-data /path/to/your/laravel/root/directory

Luego me doy los permisos a mí mismo y al servidor web:

sudo find /path/to/your/laravel/root/directory -type f -exec chmod 664 {} /; sudo find /path/to/your/laravel/root/directory -type d -exec chmod 775 {} /;

Luego, otorgue al servidor web los derechos de lectura y escritura en el almacenamiento y el caché

De cualquier forma que lo configure, debe otorgar permisos de lectura y escritura al servidor web para almacenamiento, caché y cualquier otro directorio que el servidor web necesite cargar o escribir también (según su situación), así que ejecute los comandos de bashy arriba:

sudo chgrp -R www-data storage bootstrap/cache sudo chmod -R ug+rwx storage bootstrap/cache

Ahora, estás seguro y tu sitio web funciona, Y puedes trabajar con los archivos con bastante facilidad.

Answer 13

Tenía la siguiente configuración:

• NGINX (usuario en ejecución: nginx )
• PHP-FPM

Y aplicó los permisos correctamente como @bgies sugirió en la respuesta aceptada. El problema en mi caso fue el usuario y el grupo configurados en ejecución de php-fpm, que originalmente era apache .

Si está utilizando NGINX con php-fpm, debe abrir el archivo de configuración de php-fpm:

nano /etc/php-fpm.d/www.config

Y reemplace el valor de las opciones de user y group con un NGINX configurado para trabajar; en mi caso, ambos eran nginx :

... ; 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 ...

Guárdelo y reinicie los servicios nginx y php-fpm.