¿Cómo configurar permisos de archivo para Laravel?

Estoy usando el servidor web Apache que tiene configurado el propietario _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 que la /storagecarpeta se pueda escribir. Encontré muchos enfoques diferentes para que funcione y generalmente termino haciéndolo 777chmod de forma recursiva. Sin embargo, sé que no es la mejor idea.

El documento oficial dice:

Laravel puede requerir que se configuren algunos permisos: carpetas dentro storagey vendorrequiere acceso de escritura por parte del servidor web.

¿Significa que el servidor web también necesita acceso a las carpetas storagey a vendorellos mismos 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 _www:_wwwy eso hizo que el sitio funcionara correctamente, como si cambiara a chmod 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. Cambio 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

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 malintencionada 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 / ruta / a / your / laravel / root / directory -type f -exec chmod 644 {} \;    

SET permisos de directorio

sudo find / ruta / a / 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 permisos a mí mismo y al servidor web:

sudo find / ruta / a / your / laravel / root / directory -type f -exec chmod 664 {} \;    
sudo find / ruta / a / your / laravel / root / directory -type d -exec chmod 775 {} \;

Luego, otorgue al servidor web los derechos para leer y escribir 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 bootstrap / caché de almacenamiento
sudo chmod -R ug + rwx almacenamiento bootstrap / caché

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

Los permisos para las carpetas storagey vendordeben permanecer en 775, por razones obvias de seguridad.

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 registro storage.

Todo lo que necesita hacer es ceder 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 ella username) al grupo al que pertenece el servidor Apache. Al igual que :

sudo usermod -a -G www-data userName

NOTA: Con mayor frecuencia, groupNamees www-datapero en su caso, sustituirlo por_www

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

Descubrí 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 www-datausuario 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 www-datausuario y el usuario de la aplicación ( deployacceso de escritura) a la carpeta de almacenamiento, independientemente del usuario que posee el archivo (por lo tanto deployy www-datase puede 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-xpermisos y los archivos tengan -rw-r--r--.
2. sudo chown -R deploy:deploy application/(o simplemente implemente su aplicación como deployusuario, que es lo que hacemos).
3. chgrp www-data application/para dar www-dataacceso al grupo a la aplicación.
4. chmod 750 application/para permitir al deployusuario leer / escribir, el www-datausuario de solo lectura y eliminar todos los permisos a cualquier otro usuario.
5. setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/para establecer los permisos predeterminados en la storage/carpeta y todas las subcarpetas. Cualquier carpeta / archivo nuevo creado en la carpeta de almacenamiento heredará estos permisos ( rwxpara ambos www-datay deploy).
6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/ para establecer los permisos anteriores en cualquier archivo / carpeta existente.

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

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

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

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

Como ya publicado

Todo lo que necesita hacer es ceder 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

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

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 composer install

Los documentos de Laravel 5.4 dicen:

Después de instalar Laravel, es posible que deba configurar algunos permisos. Directorios dentro de la storagey los bootstrap/cachedirectorios deben tener permisos de escritura por el servidor web o laravel no se ejecutarán. 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 777permisos. 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 deba averiguar a qué usuario se está ejecutando su aplicación al ejecutar whoamien el terminal y luego cambiar la propiedad de ciertos directorios usando chown -R.

Si no tiene permiso para usarlo, sudoya 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 funcionaba completamente porque los permisos de los directorios storagey bootstrap/cacheestaban en mal estado).

Necesitaba usar:

Cloudways Platform > Server > Application Settings > Reset Permission

Entonces podría correr php artisan cache:clearen la terminal.

La solución publicada por bgles es perfecta 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á permisos diferentes 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 y un artesano conectados. 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. Así que 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. Utilizamos 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 recrear 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.

final de edición

Cambios para Systemd

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

El servicio systemd estándar debe ser reemplazado, 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

Esto funcionó para mí:

cd [..LARAVEL PROJECT ROOT]
sudo find . -type f -exec chmod 644 {} \;
sudo find . -type d -exec chmod 755 {} \;
sudo chmod -R 777 ./storage
sudo chmod -R 777 ./bootstrap/cache/

Que hace:

• Cambiar todos los permisos de archivo a 644
• Cambiar todos los permisos de carpeta a 755
• Para el almacenamiento y la memoria caché de arranque (carpetas especiales utilizadas por laravel para crear y ejecutar archivos, no disponibles desde el exterior), establezca el permiso en 777, para cualquier cosa dentro

Nota: Quizás no pueda o no necesite hacerlo con el prefijo sudo. depende de los permisos de su usuario, grupo, etc.

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

Ejecute lo siguiente dentro de la raíz de su 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.

He instalado laravel en la instancia EC2 y he pasado 3 días para corregir el error de permiso y finalmente lo solucioné. Por eso 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 transmisión 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 darle 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

Tenía la siguiente configuración:

• NGINX (usuario que ejecuta: 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 originalmenteapache .

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 reemplazar user y groupopciones con un NGINX está configurado para funcionar; en mi caso, ambos fueron 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.

Para los desarrolladores de Laravel, los problemas de directorio pueden ser un poco molestos. En mi aplicación, estaba creando directorios sobre la marcha y moviendo archivos a este directorio en mi entorno local con éxito. Luego, en el servidor, recibía errores al mover archivos al directorio recién creado.

Aquí están las cosas que hice y obtuve un resultado exitoso al final.

1. 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 {} \;
2. chcon -Rt httpd_sys_content_rw_t /path/to/my/file/upload/directory/in/laravel/project/
3. Al crear el nuevo directorio sobre la marcha, utilicé el comando mkdir($save_path, 0755, true);

Después de hacer esos cambios en el servidor de producción, creé con éxito nuevos directorios y moví archivos a ellos.

Finalmente, si usa File fachada en Laravel, puede hacer algo como esto: File::makeDirectory($save_path, 0755, true);

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"

luego:

sudo systemctl reload php7.0-fpm