web-dev-qa-db-fra.com

Comment configurer les autorisations de fichiers pour Laravel 5 (et autres)

J'utilise Apache Web Server dont le propriétaire est défini sur _www:_www. Je ne sais jamais quelle est la meilleure pratique avec les autorisations de fichiers, par exemple lorsque je crée un nouveau projet Laravel 5.

Laravel 5 requiert que le dossier /storage soit accessible en écriture. J'ai trouvé de nombreuses approches différentes pour le faire fonctionner et je finis généralement par le rendre récursivement 777 chmod. Je sais que ce n'est pas la meilleure idée cependant.

Le doc officiel dit:

Laravel peut nécessiter la configuration de certaines autorisations: dossiers au sein de storage et vendor nécessitent un accès en écriture du serveur Web.

Cela signifie-t-il que le serveur Web doit lui aussi accéder aux dossiers storage et vendor ou à leur contenu actuel?

Je suppose que ce qui est beaucoup mieux, change le propriétaire au lieu des autorisations. J'ai changé récursivement toutes les autorisations de fichiers de Laravel en _www:_www et cela a permis au site de fonctionner correctement, comme si j'avais changé chmod en 777. Le problème est que maintenant mon éditeur de texte me demande un mot de passe chaque fois que je veux enregistrer un fichier, et il en va de même si j'essaie de modifier quoi que ce soit dans le Finder, comme par exemple copier un fichier.

Quelle est la bonne approche pour résoudre ces problèmes?

  1. Changer chmod
  2. Changez le propriétaire des fichiers pour qu'ils correspondent à ceux du fichier serveur Web et peut-être définir l'éditeur de texte (et le Finder?) pour ignorer demander le mot de passe, ou les obliger à utiliser Sudo
  3. Changez le propriétaire du serveur Web pour qu’il corresponde à l’utilisateur système (je ne connais pas les conséquences)
  4. Autre chose
phpapachelaravellaravel-5file-permissions
121
Robo Robok

Pour énoncer une évidence pour quiconque visionnant cette discussion .... si vous accordez des autorisations à l'un de vos dossiers 777, vous permettez à quiconque de lire, écrire et exécuter n'importe quel fichier de ce répertoire ... ce que cela signifie, c'est que vous l'avez Toute personne (tout pirate informatique ou personne malveillante dans le monde entier) est autorisée à télécharger tout fichier, virus ou tout autre fichier, et ALORS exécuter ce fichier ... 

Si vous configurez vos autorisations de dossier sur 777, vous avez ouvert votre fichier SERVEUR À QUI PEUT TROUVER CET ANNUAIRE. Suffisamment clair??? :)

Il existe essentiellement deux façons de configurer votre propriété et vos autorisations. Soit vous vous donnez la propriété ou vous faites du serveur Web le propriétaire de tous les fichiers.

Serveur Web en tant que propriétaire (comme la plupart des gens le font et comme le fait le doc Laravel):

en supposant que www-data (ce pourrait être quelque chose d'autre) est votre utilisateur de serveur web.

    Sudo chown -R www-data: www-data/chemin/vers/votre/laravel/root/répertoire

si vous le faites, le serveur Web possède tous les fichiers et constitue également le groupe. Vous rencontrerez parfois des difficultés pour télécharger des fichiers ou travailler avec des fichiers via FTP, car votre client FTP sera connecté en tant que vous, pas votre serveur Web. votre utilisateur au groupe d'utilisateurs du serveur Web:

   Sudo usermod -a -G www-data ubuntu

Bien entendu, cela suppose que votre serveur Web est exécuté en tant que www-data (la valeur par défaut de Homestead) et que votre utilisateur est ubuntu (il est vagabond si vous utilisez Homestead).

Ensuite, vous définissez tous vos répertoires sur 755 et vos fichiers sur 644 ... Autorisations de fichiers SET

Sudo trouve/chemin/vers/votre/laravel/racine/répertoire -type f -exec chmod 644 {} \; 

Autorisations de répertoire SET

Recherchez le chemin/path/to/votre/laravel/root/directory -type d -exec chmod 755 {} \;

Votre utilisateur en tant que propriétaire

Je préfère posséder tous les répertoires et fichiers (cela facilite beaucoup le travail avec tout), alors je fais: 

Sudo chown -R mon-utilisateur: www-data/chemin/vers/votre/laravel/root/répertoire

Ensuite, je donne à moi-même et au serveur Web les autorisations suivantes: 

Sudo trouve/chemin/vers/votre/laravel/racine/répertoire -type f -exec chmod 664 {} \; 
 Sudo cherche/chemin/vers/votre/laravel/racine/répertoire -type d -exec chmod 775 {} \;

Ensuite, donnez au serveur Web les droits de lecture et d'écriture sur le stockage et le cache

Quelle que soit la manière dont vous l'avez configurée, vous devez alors donner des autorisations de lecture et d'écriture au serveur Web pour le stockage, le cache et tous les autres répertoires que le serveur Web doit télécharger ou écrire également (selon votre situation), exécutez donc les commandes de bashy ci-dessus:

Sudo chgrp -R Bootstrap/cache de stockage www-data 
 Sudo chmod -R ug + bootstrap/cache de stockage rwx

Maintenant, vous êtes en sécurité et votre site Web fonctionne, ET vous pouvez travailler avec les fichiers assez facilement

376
bgies

Les autorisations pour les dossiers storage et vendor doivent 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 telles que php artisan, votre ordinateur doit écrire dans le fichier journal dans storage.

Tout ce que vous avez à 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 sa username) au groupe auquel appartient le serveur Apache. Ainsi : 

Sudo usermod -a -G www-data userName

NOTE: Le plus souvent, groupName est www-data mais dans votre cas, remplacez-le par _www

36
BassMHL

Modifiez les autorisations de votre dossier de projet pour activer la lecture/écriture/exécution pour tout utilisateur du groupe possédant le répertoire (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
12
Bogdan

Nous avons rencontré de nombreux cas Edge lors de la configuration des autorisations pour les applications Laravel. Nous créons un compte utilisateur distinct (deploy) pour posséder le dossier de l'application Laravel et exécuter les commandes Laravel à partir de la CLI, et exécutons le serveur Web sous www-data. Ceci est dû au fait que le ou les fichiers journaux peuvent appartenir à www-data ou deploy, en fonction de celui qui a écrit le fichier journal en premier, ce qui empêche évidemment l'autre utilisateur de l'écrire ultérieurement.

J'ai constaté que la seule solution saine et sécurisée consiste à utiliser les listes de contrôle d'accès Linux. Le but de cette solution est:

  1. Pour permettre à l'utilisateur qui possède/déploie l'application, l'accès en lecture et en écriture au code de l'application Laravel (nous utilisons un utilisateur nommé deploy).
  2. Permettre à l'utilisateur www-data d'accéder en lecture au code de l'application Laravel, mais pas en écriture.
  3. 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) à accéder en écriture au dossier de stockage, quel que soit l'utilisateur propriétaire du fichier (par exemple, deploy et www-data peuvent écrire dans le même fichier journal).

Nous accomplissons ceci comme suit:

  1. Tous les fichiers du dossier application/ sont créés avec le umask par défaut de 0022, ce qui entraîne des dossiers dotés des autorisations drwxr-xr-x et des fichiers ayant -rw-r--r--.
  2. Sudo chown -R deploy:deploy application/ (ou simplement déployez votre application en tant qu'utilisateur deploy, ce que nous faisons).
  3. chgrp www-data application/ pour donner au groupe www-data l'accès à l'application.
  4. chmod 750 application/ pour autoriser l'utilisateur deploy à lire/écrire, l'utilisateur www-data en lecture seule et supprimer toutes les autorisations accordées à d'autres utilisateurs.
  5. setfacl -Rdm u:www-data:rwx,u:deploy:rwx application/storage/ 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 www-data et deploy).
  6. setfacl -Rm u:www-data:rwX,u:deploy:rwX application/storage/ pour définir les autorisations ci-dessus sur tous les fichiers/dossiers existants.
11
Chris Schwerdt

Comme déjà posté 

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

mais j'ai ajouté -R pour chown command: Sudo chown -R www-data:www-data /path/to/your/project/vendor Sudo chown -R www-data:www-data /path/to/your/project/storage

7
Stanislav Potapenko

La plupart des dossiers doivent être "755" normaux et les fichiers "644"

Laravel exige que certains dossiers soient accessibles en écriture pour l'utilisateur du serveur Web. Vous pouvez utiliser cette commande sur les systèmes d'exploitation Unix.

Sudo chgrp -R www-data storage bootstrap/cache
Sudo chmod -R ug+rwx storage bootstrap/cache
4
Siddharth Joshi

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 il ya toujours des problèmes potentiels pour Laravel.

Par défaut, Apache créera des fichiers avec des autorisations 644. Donc, c'est à peu près n'importe quoi dans le stockage /. Donc, si vous supprimez le contenu de storage/framework/views, puis accédez à une page via Apache, vous constaterez que la vue en cache a été créée comme suit:

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

Si vous exécutez "artisan serve" 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, cela échouera. Et ceci peut s’appliquer aux fichiers de cache, aux vues en cache et aux journaux lors du déploiement à l’aide d’un utilisateur et d’un artisan connectés. Un exemple simple, "artisan cache: clear", 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, vous allez donc faire/écrire tout ce qui se passe comme:

Sudo -u www-data php artisan cache:clear

Ou vous en éviterez l'ennui et vous l'ajouterez à vos .bash_aliases:

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

Cela suffit et n’affecte en aucune manière la sécurité. Mais sur les machines de développement, l'exécution de scripts de test et d'assainissement rend cela fastidieux, à 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 pourrait entraîner la création de fichiers.

La solution consiste à suivre la deuxième partie du conseil de bgles, à ajouter ce qui suit dans/etc/Apache2/envvars et à redémarrer (sans recharger) Apache:

umask 002

Cela forcera Apache à créer des fichiers au format 664 par défaut. En soi, cela peut présenter un risque de sécurité. Cependant, sur les environnements Laravel dont il est principalement question ici (Homestead, Vagrant, Ubuntu), le serveur Web s'exécute en tant qu'utilisateur www-data sous le groupe www-data. Par conséquent, si vous n'autorisez pas arbitrairement les utilisateurs à rejoindre le groupe www-data, aucun risque supplémentaire ne devrait exister. Si quelqu'un parvient à sortir du serveur Web, il dispose de toute façon d'un niveau d'accès www-data, de sorte que rien n'est perdu (bien que ce ne soit pas la meilleure attitude à avoir en matière de sécurité). La production est donc relativement sûre et sur une machine de développement à utilisateur unique, ce n'est pas un problème. 

En fin de compte, étant donné que votre utilisateur appartient au groupe www-data et que tous les répertoires contenant ces fichiers sont g + s (le fichier est toujours créé sous le groupe du répertoire parent), tout élément créé par l'utilisateur ou par www-data sera r/w pour l'autre. 

Et c'est l'objectif ici.

modifier

Si vous examinez plus en détail la méthode ci-dessus pour définir les autorisations, le résultat semble toujours satisfaisant, mais quelques ajustements peuvent aider:

Par défaut, les répertoires sont au nombre de 775 et les fichiers au nombre de 664. 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 à tous les autres et de transformer le groupe en 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 de blocage de groupe signifie que ceux-ci seront la propriété du 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 de cache, de journal, de session et de vue. 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 faire cela dans bootstrap/cache car il n'y avait (normalement) aucun sous-répertoire dans celui-ci.

Vous devrez peut-être réappliquer les indicateurs de l'exécutable, supprimer fournisseur/* et réinstaller les dépendances du 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 de umask pour Apache expliqué ci-dessus, c'est tout ce dont vous avez besoin sans rendre tout le projet accessible à l'écriture par www-data, ce qui est le cas avec d'autres solutions. C'est donc un peu plus sûr en ce sens qu'un intrus fonctionnant sous www-data dispose d'un accès en écriture plus limité.

end edit

Modifications 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
3
markdwhite

Le Laravel 5.4 docs dire:

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

Il y a beaucoup de réponses sur cette page qui mentionnent l'utilisation d'autorisations 777. Ne fais pas ça. Vous seriez vous exposer à des pirates informatiques.

Suivez plutôt les suggestions d'autres personnes sur la façon de définir des autorisations de 755 (ou plus restrictives). Vous devrez peut-être déterminer sous quel utilisateur votre application est exécutée en exécutant whoami dans le terminal, puis modifiez la propriété de certains répertoires à l'aide de chown -R.

Si vous n'êtes pas autorisé à utiliser Sudo comme le demandent tant de réponses ...

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

(Dans mon cas, j'avais cloné mon application Laravel sur un de mes autres serveurs Cloudways et cela ne fonctionnait pas complètement, car les autorisations des répertoires storage et bootstrap/cache étaient altérées.)

J'avais besoin d'utiliser:

Cloudways Platform > Server > Application Settings > Reset Permission

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

2
Ryan

J'ai décidé d'écrire mon propre script pour atténuer certaines des difficultés liées à 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 démarrage soit terminé et vous êtes prêt à partir.

Consultez le script avant utilisation.

1
Jonathan

J'ai installé laravel sur une instance EC2 et ai passé 3 jours à corriger l'erreur de permission et enfin à le corriger… .. Je souhaite donc partager cette expérience avec une autre.

  1. problème d'utilisateur Lorsque je me suis connecté à l'instance ec2, mon nom d'utilisateur est ec2-user et le groupe d'utilisateurs est ec2-utilisateur . Apache.

  2. autorisation de dossier et de fichier A. Structure de dossiers Tout d’abord, vous devez vous assurer que vous avez une telle structure de dossiers comme celle-ci sous Stockage.

    espace de rangement

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

B. permission Au début, je vois les instructions pour définir 777 sous stockage pour supprimer file_put_contents: impossible d'ouvrir l'erreur de flux . Donc, je configure la permission 777 pour le stockage chmod -R 777 stockage Mais l'erreur n'a pas été corrigée . ici, vous devriez en considérer un: qui écrit des fichiers dans le stockage/les sessions et les vues . Ce n'est pas ec2-user, mais Apache . Oui, d'accord . L'utilisateur "Apache" écrit le fichier (fichier de session, fichier de vue compilé) dans la session et le dossier de vue . Vous devriez donc donner à Apache l’autorisation d’écrire dans ce dossier . Par défaut: SELinux indique que le dossier/var/www doit être en lecture seule par le démon Apache.

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

Cela peut résoudre le problème dans le temps, mais cela empêche le mysql de fonctionner . donc ce n'est pas une si 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/

Ensuite, votre problème sera résolu.

  1. et n'oubliez pas cette mise à jour du compositeur cache de l'artisan php: effacer

    Ces commandes seront utiles après ou avant.

    J'espère que vous économiserez du temps .. Bonne chance. Hacken

1
Hacken Lee

J'ai eu la configuration suivante:

  • NGINX (utilisateur en cours d'exécution: nginx)
  • PHP-FPM

Et les autorisations appliquées correctement comme @bgies suggéré dans la réponse acceptée. Le problème dans mon cas était l'utilisateur et le groupe configurés de php-fpm qui était à l'origine Apache.

Si vous utilisez NGINX avec php-fpm, vous devriez ouvrir le fichier de configuration de php-fpm:

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

Et remplacez la valeur des options user et group par un NGINX configuré pour fonctionner avec; dans mon cas, les deux étaient 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 ...

Enregistrez-le et redémarrez les services nginx et php-fpm.

0
Amirreza Nasiri

Ajouter à composer.json

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

Après composer update

0
Davron Achilov