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
777es demasiada libertad, porque incluye todos los permisos para todos.