Autorisations de fichier pour Laravel 5 (et autres)

Les autorisations pour les dossiers storage et vendor devraient rester à 775, pour des raisons de sécurité évidentes.

Cependant, votre ordinateur et votre serveur Apache doivent pouvoir écrire dans ces dossiers. Ex: lorsque vous exécutez des commandes comme php artisan, votre ordinateur doit écrire dans le fichier logs dans storage.

Tout ce que vous devez faire est de donner la propriété des dossiers à 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

Ensuite, vous devez ajouter votre ordinateur (référencé par son username) au groupe auquel le serveur Apache appartient. Comme ça:

sudo usermod -a -G www-data userName

REMARQUE:, le Plus souvent, groupName est www-data, mais dans votre cas, le remplacer par _www

Modifiez les autorisations de votre dossier de projet pour activer read / write / exec pour tout utilisateur du groupe propriétaire du répertoire (ce qui dans votre cas est _www):

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

Ajoutez ensuite votre nom D'utilisateur OS X au groupe _www pour lui permettre d'accéder au répertoire:

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

Nous avons rencontré de nombreux cas de bord lors de la configuration des autorisations pour les applications Laravel. Nous créons un compte utilisateur séparé (deploy) pour posséder le dossier D'application Laravel et exécuter les commandes Laravel à partir de L'interface de ligne de commande, et exécutons le serveur web sous www-data. Un problème que cela provoque est que le ou les fichiers journaux peuvent appartenir à www-data ou deploy, selon qui a écrit le fichier journal en premier, empêchant évidemment l'autre utilisateur d'y écrire à l'avenir.

J'ai trouvé que le seul sain d'esprit et la solution sécurisée consiste à utiliser les ACL Linux. Le but de cette solution est:

1. pour permettre à l'utilisateur qui possède / déploie l'application d'accéder en lecture et en écriture au code de L'application Laravel (nous utilisons un utilisateur nommé deploy).
2. permet à l'utilisateur www-data d'accéder en lecture au code de L'application Laravel, mais pas d'accéder en écriture.
3. pour empêcher tout autre utilisateur d'accéder au Code/aux données de L'application Laravel.
4. pour autoriser à la fois l'utilisateur www-data et l'utilisateur de l'application (deploy) écrire accès au dossier de stockage, quel que soit l'utilisateur propriétaire du fichier (donc deploy et www-data peuvent écrire dans le même fichier journal par exemple).

Nous accomplissons ceci comme suit:

1. Tous les fichiers du dossier application/ sont créés avec l'umask par défaut de 0022, ce qui entraîne des dossiers ayant des autorisations drwxr-xr-x et des fichiers ayant -rw-r--r--.
2. sudo chown -R deploy:deploy application/ (ou simplement déployer votre application en tant qu'utilisateur deploy, ce que nous faisons).
3. {[16] } pour donner le www-data Groupe accès à l'application.
4. chmod 750 application/ pour autoriser l'utilisateur deploy en lecture / écriture, l'utilisateur www-data en lecture seule et pour supprimer toutes les autorisations à d'autres utilisateurs.
5. {[21] } pour définir les autorisations par défaut sur le dossier storage/ et tous les sous-dossiers. Tous les nouveaux dossiers / fichiers créés dans le dossier de stockage hériteront de ces autorisations (rwx pour les www-data et deploy).
6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/ pour définir les autorisations ci-dessus sur les fichiers/dossiers.

Comme affiché déjà

Tout ce que vous devez faire est de donner la propriété des dossiers à Apache:

, Mais j'ai ajouté R pour chown commande: 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 plupart des dossiers doivent être normaux " 755 "et les fichiers," 644 "

Laravel nécessite que certains dossiers soient inscriptibles pour l'utilisateur du serveur web. Vous pouvez utiliser cette commande sur les systèmes d'exploitation basés sur unix.

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

La solution Postée par bgles est parfaite pour moi en termes de définition correcte des autorisations initialement (j'utilise la deuxième méthode), mais elle a toujours des problèmes potentiels pour Laravel.

Par défaut, Apache crée des fichiers avec 644 autorisations. Donc, c'est à peu près n'importe quoi dans le stockage/. Donc, si vous supprimez le contenu de storage / framework / views, accédez à une page via Apache, vous trouverez 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 servir" et accédez à une page différente, vous obtiendrez des autorisations différentes 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 ceci peut s'appliquer aux fichiers de cache, aux vues et aux journaux mis en cache lors du déploiement à l'aide d'un utilisateur connecté et d'un artisan. Un exemple facile étant "artisan cache: clear" qui échouera à supprimer tous les fichiers de cache qui sont www-data: www-data 644.

Cela peut être partiellement atténué en exécutant des commandes artisan en tant que www-data, de sorte que vous allez faire / Scripter tout comme:

sudo -u www-data php artisan cache:clear

Ou vous éviterez l'ennui de cela et ajoutez ceci à votre .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, sauf si vous souhaitez configurer des alias pour utiliser ' sudo-u www-data ' pour exécuter phpunit et tout ce que vous vérifiez vos builds avec qui pourrait provoquer la création de fichiers.

La solution consiste à suivre la deuxième partie des conseils de bgles, et à 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, ce qui peut présenter un risque de sécurité. Cependant, sur les environnements Laravel principalement discutés ici (Homestead, Vagrant, Ubuntu), le serveur web s'exécute en tant qu'utilisateur www-data dans 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 parvient à 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, sur la 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 que 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), créés par l'utilisateur ou par www-data sera r/w pour les autres.

Et c'est le but ici.

modifier

En examinant l'approche ci-dessus pour définir les autorisations plus loin, cela semble toujours assez bon, mais quelques réglages 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 a installé le framework. Supposons donc que nous commencions à partir 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 www-data. Seuls le propriétaire et les membres de www-data peuvent accéder au répertoire.

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

Pour permettre au serveur web de créer des services.JSON et compilé.php, comme suggéré par le guide D'installation officiel de Laravel. Définir le bit collant du 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 cache, journal, session et afficher les fichiers. 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.

Vous devrez peut-être réappliquer tous les indicateurs exécutables, supprimer les dépendances vendor/* et réinstaller composer pour recréer des liens pour phpunit et al., par exemple:

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

C'est ça. À l'exception de l'umask pour Apache expliqué ci-dessus, c'est tout ce qui est nécessaire sans rendre l'ensemble projectroot accessible en écriture par www-data, ce qui se passe avec d'autres solutions. Il est donc légèrement plus sûr de cette façon en ce sens qu'un intrus fonctionnant en tant que www-data a un accès en écriture plus limité.

fin de l'édition

Changements pour Systemd

Ceci s'applique à l'utilisation de php-fpm, mais peut-être d'autres trop.

Le service systemd standard doit être remplacé, l'umask défini dans le override.fichier 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

J'ai décidé d'écrire mon propre script pour soulager une partie de la douleur de la mise en place de projets.

Exécutez ce qui suit dans la racine de votre projet:

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

Attendez que le bootstrapping se termine et vous êtes prêt à partir.

Vérifiez le script avant utilisation.

Les documents Laravel 5.4 disent:

Après avoir installé Laravel, vous devrez peut-être configurer certaines autorisations. Répertoires dans les répertoires storage et bootstrap/cache doit être accessible en écriture par votre serveur web ou Laravel ne fonctionnera pas. Si vous utilisez la machine virtuelle Homestead, ces autorisations devraient être déjà réglé.

Il y a beaucoup de réponses sur cette page qui mentionnent l'utilisation des autorisations 777. Ne pas le faire. Tu serais vous exposer {[12] } aux pirates.

Au lieu de cela, suivez les suggestions des autres sur la façon de définir des autorisations de 755 (ou plus restrictives). Vous devrez peut-être déterminer quel utilisateur fonctionne votre application en exécutant whoami dans le terminal, puis changer la propriété de certains répertoires en utilisant chown -R.

Si vous n'avez pas la permission d'utiliser sudo, comme beaucoup d'autres nécessitent des réponses...

Votre serveur est probablement un hôte partagé tel que Cloudways.

(dans mon dans ce cas, j'avais cloné mon application Laravel dans un deuxième serveur Cloudways, et cela ne fonctionnait pas complètement parce que les autorisations des répertoires storage et bootstrap/cache étaient foiré.)

J'avais besoin d'utiliser:

Cloudways Platform > Server > Application Settings > Reset Permission

Ensuite, je pourrais exécuter php artisan cache:clear dans le terminal.

J'ai installé laravel sur l'instance EC2 et j'ai passé 3 jours pour corriger l'erreur d'autorisation et l'ai enfin corrigé. Donc, je veux partager cette expérience avec un autre.

1. Problème utilisateur Lorsque je me suis connecté à l'instance ec2, mon nom d'utilisateur est ec2-user et usergroup est ec2-user. Et le site fonctionne sous httpd utilisateur: apache: apache nous devrions donc définir l'autorisation pour apache.

2. Dossier et autorisation de fichier A. structure des dossiers tout d'abord, vous devez vous assurer que vous avoir une telle structure de dossier comme celle-ci sous storage

   Stockage

   • cadre
     • cache
     • sessions
     • vues
   • journaux La structure des dossiers peut être différente selon la version laravel que vous utilisez. ma version laravel est 5.2 et vous pouvez trouver la structure appropriée en fonction de votre version.

B. autorisation Au début, je vois les instructions pour définir 777 sous stockage pour supprimer file_put_contents: failed to open stream erreur. J'ai donc configuré l'autorisation 777 pour le stockage stockage chmod-R 777 Mais l'erreur n'a pas été fixé. ici, vous devriez en considérer un: qui écrit des fichiers dans le stockage / sessions et vues. Ce n'est pas ec2-utilisateur, mais apache. Oui, à droite. l'utilisateur "apache" écrit le fichier (fichier de session, fichier de vue compilé) dans le dossier session et view. Vous devriez donc donner à apache l'autorisation d'écrire dans ces dossiers. Par défaut: SELinux dit que le dossier/var / www doit être en lecture seule par l'apache deamon.

Donc, pour cela, nous pouvons définir le selinux comme 0: setenforce 0

Cela peut résoudre le problème temporellement, mais cela rend le mysql ne fonctionne pas. donc, ce n'est pas une bonne solution.

Vous pouvez définir un contexte de lecture-écriture dans le dossier de stockage avec: (n'oubliez pas de setenforce 1 pour le tester)

chcon -Rt httpd_sys_content_rw_t storage/

Alors votre problème sera corrigé.

1. Et n'oublie pas ça mise à jour du compositeur php artisan cache: Effacer

   Ces commandes seront utiles après ou avant.

   J'espère que vous gagnez votre temps. Bonne chance. Hacken

Ajouter au compositeur.json

"scripts": {
...
"post-update-cmd": [
      "chmod -R 777 storage",
      "chmod -R 775 bootstrap/cache",
      "chmod 775 vendor"
    ]
...
}

Après composer update

J'ai trouvé une solution encore meilleure à cela. C'est dû au fait que php s'exécute en tant qu'autre utilisateur par défaut.

Donc, pour résoudre ce problème, faites

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

Puis modifiez le user = "put user that owns the directories" group = "put user that owns the directories"

Puis:

sudo systemctl reload php7.0-fpm