La solution publiée par bgles est parfaite pour moi en termes de définition correcte des autorisations au départ (j'utilise la deuxième méthode), mais elle a toujours des problèmes potentiels pour Laravel.
Par défaut, Apache créera des fichiers avec 644 autorisations. C'est donc à peu près tout dans le stockage /. Donc, si vous supprimez le contenu de stockage / framework / vues, puis accédez à une page via Apache, vous constaterez que la vue en cache a été créée comme:
-rw-r--r-- 1 www-data www-data 1005 Dec 6 09:40 969370d7664df9c5206b90cd7c2c79c2
Si vous exécutez "artisan serve" et accédez à une autre page, vous obtiendrez différentes autorisations car CLI PHP se comporte différemment d'Apache:
-rw-rw-r-- 1 user www-data 16191 Dec 6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e
En soi, ce n'est pas grave car vous ne ferez rien de tout cela en production. Mais si Apache crée un fichier qui doit ensuite être écrit par l'utilisateur, il échouera. Et cela peut s'appliquer aux fichiers de cache, aux vues mises en cache et aux journaux lors du déploiement à l'aide d'un utilisateur connecté et d'un artisan. Un exemple facile étant "artisan cache: clear" qui ne supprimera pas les fichiers de cache qui sont www-data: www-data 644.
Cela peut être partiellement atténué en exécutant des commandes artisanales en tant que www-data, donc vous ferez / scripterez tout comme:
sudo -u www-data php artisan cache:clear
Ou vous éviterez la fastidieuse de ceci et l'ajouterez à vos .bash_aliases:
alias art='sudo -u www-data php artisan'
C'est assez bon et n'affecte en rien la sécurité. Mais sur les machines de développement, l'exécution de scripts de test et d'assainissement rend cela difficile, à moins que vous ne vouliez configurer des alias pour utiliser 'sudo -u www-data' pour exécuter phpunit et tout ce que vous vérifiez avec vos builds qui pourrait entraîner la création de fichiers.
La solution consiste à suivre la deuxième partie des conseils bgles, à ajouter ce qui suit à / etc / apache2 / envvars et à redémarrer (pas recharger) Apache:
umask 002
Cela forcera Apache à créer des fichiers comme 664 par défaut. En soi, cela peut présenter un risque pour la sécurité. Cependant, sur les environnements Laravel principalement discutés ici (Homestead, Vagrant, Ubuntu), le serveur Web fonctionne en tant qu'utilisateur www-data sous le groupe www-data. Donc, si vous n'autorisez pas arbitrairement les utilisateurs à rejoindre le groupe www-data, il ne devrait pas y avoir de risque supplémentaire. Si quelqu'un réussit à sortir du serveur Web, il a de toute façon un niveau d'accès aux données www, donc rien n'est perdu (bien que ce ne soit pas la meilleure attitude à avoir en matière de sécurité). Donc, en production, c'est relativement sûr et sur une machine de développement mono-utilisateur, ce n'est tout simplement pas un problème.
En fin de compte, comme votre utilisateur est dans le groupe www-data, et tous les répertoires contenant ces fichiers sont g + s (le fichier est toujours créé sous le groupe du répertoire parent), tout ce qui est créé par l'utilisateur ou par www-data sera r / w pour l'autre.
Et c'est le but ici.
Éditer
En étudiant plus en détail l'approche ci-dessus pour définir des autorisations, cela semble toujours assez bon, mais quelques ajustements peuvent aider:
Par défaut, les répertoires sont 775 et les fichiers sont 664 et tous les fichiers ont le propriétaire et le groupe de l'utilisateur qui vient d'installer le framework. Supposons donc que nous partons de ce point.
cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./
La première chose que nous faisons est de bloquer l'accès à tout le monde et de faire du groupe des www-data. Seuls le propriétaire et les membres de www-data peuvent accéder à l'annuaire.
sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache
Pour permettre au serveur Web de créer services.json et compiled.php, comme suggéré par le guide d'installation officiel de Laravel. La définition du bit collant de groupe signifie que ceux-ci appartiendront au créateur avec un groupe de www-data.
find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage
Nous faisons la même chose avec le dossier de stockage pour permettre la création de fichiers cache, log, session et view. Nous utilisons find pour définir explicitement les autorisations de répertoire différemment pour les répertoires et les fichiers. Nous n'avions pas besoin de le faire dans bootstrap / cache car il n'y a (normalement) aucun sous-répertoire dedans.
Vous devrez peut-être réappliquer tous les indicateurs exécutables, supprimer le fournisseur / * et réinstaller les dépendances de compositeur pour recréer des liens pour phpunit et al, par exemple:
chmod +x .git/hooks/*
rm vendor/*
composer install -o
C'est tout. À l'exception du umask pour Apache expliqué ci-dessus, c'est tout ce qui est nécessaire sans rendre la totalité de la racine du projet accessible en écriture par www-data, ce qui se produit avec d'autres solutions. Il est donc légèrement plus sûr de cette façon, car un intrus fonctionnant en tant que www-data a un accès en écriture plus limité.
terminer l'édition
Changements pour Systemd
Cela s'applique à l'utilisation de php-fpm, mais peut-être à d'autres aussi.
Le service systemd standard doit être remplacé, le umask défini dans le fichier override.conf et le service redémarré:
sudo systemctl edit php7.0-fpm.service
Use:
[Service]
UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service
777c'est trop de liberté, car cela inclut toutes les autorisations pour tout le monde.