Comment configurer les autorisations Linux pour le dossier WWW?
Résumé mis à jour
Le répertoire/var/www appartient à root:root ce qui veut dire que personne ne peut l'utiliser et c'est totalement inutile. Puisque nous voulons tous un serveur Web qui fonctionne réellement (et que personne ne devrait se connecter en tant que "root"), nous devons résoudre ce problème.
Seules deux entités ont besoin d'accéder.
PHP/Perl/Ruby/Python ont tous besoin d'accéder aux dossiers et fichiers car ils en créent beaucoup (c'est-à-dire
/uploads/). Ces langages de script devraient s'exécuter sous nginx ou Apache (ou même quelque chose comme FastCGI pour PHP).Les développeurs
Comment obtiennent-ils l'accès? Je sais que quelqu'un, quelque part l'a déjà fait. Avec cependant des milliards de sites Web, vous penseriez qu'il y aurait plus d'informations sur ce sujet.
Je sais que 777 est une autorisation complète de lecture/écriture/exécution pour le propriétaire/groupe/autre. Donc cela ne semble pas être nécessaire correct car il donne aux utilisateurs aléatoires des autorisations complètes.
Quelles autorisations doivent être utilisées sur /var/www pour que:
- Contrôle de source comme git ou svn
- Utilisateurs d'un groupe comme "sites Web" ( ou même ajoutés à "www-data")
- Des serveurs comme Apache ou lighthttpd
- Et PHP/Perl/Ruby
peuvent tous y lire, créer et exécuter des fichiers (et répertoires)?
Si j'ai raison, Ruby et PHP ne sont pas "exécutés" directement - mais transmis à un interprète. fichiers dans /var/www...? Par conséquent, il semble que l'autorisation correcte serait chmod -R 1660 ce qui ferait
- tous les fichiers partageables par ces quatre entités
- tous les fichiers non exécutable par erreur
- bloquer tout le monde du répertoire entièrement
- définir le mode d'autorisation sur "collant" pour tous les futurs fichiers
Est-ce correct?
Mise à jour 1: Je viens de réaliser que les fichiers et les répertoires peuvent avoir besoin d'autorisations différentes - je parlais des fichiers ci-dessus, donc je ne suis pas sûr de ce que seraient les autorisations de répertoire besoin d'être.
Mise à jour 2: La structure des dossiers de /var/www change radicalement car l'une des quatre entités ci-dessus ajoute toujours (et parfois supprime) des dossiers et sous-dossiers à plusieurs niveaux. Ils créent et suppriment également des fichiers auxquels les 3 autres entités pourraient avoir besoin d'un accès en lecture/écriture. Par conséquent, les autorisations doivent effectuer les quatre opérations ci-dessus pour les fichiers et les répertoires. Puisqu'aucun d'eux ne devrait avoir besoin d'une autorisation d'exécution (voir la question sur Ruby/php ci-dessus), je suppose que rw-rw-r-- l'autorisation serait tout ce qui est nécessaire et complètement sûre puisque ces quatre entités sont gérées par du personnel de confiance (voir # 2) et tous les autres utilisateurs du système n'ont qu'un accès en lecture.
Mise à jour 3: Ceci concerne les machines de développement personnel et les serveurs d'entreprises privées. Pas de "clients Web" aléatoires comme un hôte partagé.
Mise à jour 4: Cet article par slicehost semble être le meilleur pour expliquer ce qui est nécessaire pour configurer les autorisations pour votre dossier www. Cependant, je ne sais pas quel utilisateur ou groupe Apache/nginx avec PHP OR svn/git s'exécuter et comment les changer).
Mise à jour 5: J'ai (je pense) enfin trouvé un moyen de faire fonctionner tout cela (réponse ci-dessous). Cependant, je ne sais pas si c'est la manière correcte et sécurisée de le faire. J'ai donc commencé une prime. La personne qui a la meilleure méthode pour sécuriser et gérer le répertoire www gagne.
Après plus de recherches, il semble qu'une autre solution (peut-être meilleure) serait de configurer le dossier www de cette manière.
Sudo usermod -a -G developer user1(ajouter chaque utilisateur au groupe de développeurs)Sudo chgrp -R developer /var/www/site.com/pour que les développeurs puissent y travaillerSudo chmod -R 2774 /var/www/site.com/pour que seuls les développeurs puissent créer/éditer des fichiers (autre/world peut lire)Sudo chgrp -R www-data /var/www/site.com/uploadspour que www-data (Apache/nginx) puisse créer des chargements.
Puisque git s'exécute comme n'importe quel utilisateur l'appelle, alors tant que l'utilisateur est dans le groupe "développeur", il devrait pouvoir créer des dossiers, éditer des fichiers PHP, et gérer le référentiel git.
Remarque: à l'étape (3): "2" en 2774 signifie "définir l'ID de groupe" pour le répertoire. Cela fait que les nouveaux fichiers et sous-répertoires créés en son sein héritent de l'ID de groupe du répertoire parent (au lieu du groupe principal de l'utilisateur) Référence: http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories
Je ne sais pas si c'est "bien", mais voici ce que je fais sur mon serveur:
- / var/www contient un dossier pour chaque site Web.
- Chaque site Web a un propriétaire désigné, qui est défini comme le propriétaire de tous les fichiers et dossiers du répertoire du site Web.
- Tous les utilisateurs qui gèrent le site Web sont placés dans un groupe pour le site Web.
- Ce groupe est défini comme le propriétaire du groupe de tous les fichiers et dossiers du répertoire.
- Tous les fichiers ou dossiers qui doivent être écrits par le serveur Web (c'est-à-dire PHP) ont leur propriétaire changé en www-data, l'utilisateur sous lequel Apache s'exécute.
Gardez à l'esprit que vous devez activer le bit d'exécution sur les répertoires afin de pouvoir répertorier le contenu.
Après avoir fait plus de recherches, il semble que git/svn TOOLS ne sont PAS un problème car ils fonctionnent comme n'importe quel utilisateur les utilisant. (Cependant, les démons git/svn sont une affaire différente!) Tout ce que j'ai créé/cloné avec git avait mes autorisations et l'outil git était répertorié dans /usr/bin qui correspond à cette thèse.
Autorisations Git résolues.
Les autorisations utilisateur semblent être résolubles en ajoutant tous les utilisateurs qui ont besoin d'accéder au répertoire www au www-data groupe sous lequel Apache (et nginx) s'exécutent.
Il semble donc que ne réponse à cette question va comme ceci:
Par défaut /var/www Est détenue par root:root et personne peut y ajouter ou modifier des fichiers.
1) Changer le propriétaire du groupe
Nous devons d'abord changer le groupe d'annuaires www qui appartiendra à "www-data" au lieu du groupe "root"
Sudo chgrp -R www-data /var/www
2) Ajouter des utilisateurs à www-data
Ensuite, nous devons ajouter l'utilisateur actuel (et toute autre personne) au groupe www-data
Sudo usermod -a -G www-data demousername
3) Annuaire CHMOD www
Modifiez les autorisations afin que SEUL le propriétaire (root) et tous les utilisateurs du groupe "www-data" puissent rwx (lire/écrire/exécuter) les fichiers et répertoires ( personne d'autre ne devrait même être pouvoir y accéder ).
Sudo chmod -R 2770 /var/www
Désormais, tous les fichiers et répertoires créés par tout utilisateur ayant accès (c'est-à-dire dans le groupe "www-data") seront lisibles/inscriptibles par Apache et donc php.
Est-ce correct? Qu'en est-il des fichiers créés par PHP/Ruby - les utilisateurs de www-data peuvent-ils y accéder?
L'adhérence n'est pas l'héritage des autorisations. L'adhérence sur un répertoire signifie que seul le propriétaire d'un fichier ou le propriétaire du répertoire peut renommer ou supprimer ce fichier dans le répertoire, malgré les autorisations contraires. Ainsi 1777 sur/tmp /.
Dans Unix classique, il n'y a pas d'héritage d'autorisations basé sur le système de fichiers, uniquement sur le umask du processus en cours. Sur * BSD, ou Linux avec setgid sur le répertoire, le champ de groupe des fichiers nouvellement créés sera défini sur le même que celui du répertoire parent. Pour quoi que ce soit de plus, vous devez examiner les ACL, avec l'ACL par défaut sur les répertoires, qui vous permettent d'avoir des autorisations héritées.
Vous devez commencer par définir: * quels utilisateurs ont accès au système * quel est votre modèle de menace
Par exemple, si vous faites de l'hébergement Web avec plusieurs clients et que vous ne voulez pas qu'ils voient les fichiers les uns des autres, vous pouvez utiliser un groupe commun "webcusts" pour tous ces utilisateurs et un mode répertoire de 0705. Ensuite, les fichiers servis par le processus du serveur web (pas dans "webcusts") verra les autres perms et sera autorisé; les clients ne peuvent pas voir les fichiers des autres et les utilisateurs peuvent jouer avec leurs propres fichiers. Cependant, cela signifie que le moment où vous autorisez CGI ou PHP vous avez pour vous assurer que les processus s'exécutent en tant qu'utilisateur spécifique (bonne pratique de toute façon, pour plusieurs) utilisateurs sur un seul hôte, pour la responsabilité). Sinon, les clients pourraient se salir les fichiers les uns des autres en faisant faire un CGI.
Cependant, si l'utilisateur d'exécution d'un site Web est le même que le propriétaire du site Web, vous ne pouvez pas protéger le contenu contre les abuseurs en cas de faille de sécurité dans le script. C'est là que les hôtes dédiés gagnent, afin que vous puissiez avoir un utilisateur d'exécution distinct du propriétaire du contenu statique et ne pas avoir à vous soucier autant de l'interaction avec d'autres utilisateurs.
Je crois que la meilleure façon de le faire est d'utiliser les listes de contrôle d'accès Posix. Ils sont confortables à utiliser et offrent toutes les fonctionnalités dont vous avez besoin.
http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs
Le propriétaire du fichier doit être la personne qui le crée, tandis que le groupe doit être www-data. Le mode des répertoires/fichiers est alors en général 755/644. Alors que pour les répertoires et les fichiers, le groupe a besoin d'un accès en écriture, le mod est 775/664. Supposons que paddy soit le développeur. Au total, cela fait:
chown -R paddy:www-data /var/www/websiteindevelopment
chmod -R 755 /var/www/websiteindevelopment
chmod -R 775 /var/www/websiteindevelopment/directorywritablebygroup
find /var/www/websiteindevelopment -type f -perm 755 -print -exec chmod 644 {} \;
find /var/www/websiteindevelopment -type f -perm 775 -print -exec chmod 664 {} \;
En ajoutant à la réponse de @ Xeoncross, je pense qu'il serait bon de configurer séparément les autorisations sur les fichiers et les répertoires.
Sudo find /var/www -type d -exec chmod 775 {} \; # Change permissions of directories to rwxrwxr-x
Sudo find /var/www -type f -exec chmod 664 {} \; # Change file permissions to rw-rw-r--
Cela permettra aux développeurs de créer et de modifier des répertoires dans/var/www. Ce qui semble important car les développeurs peuvent avoir besoin de créer des répertoires supplémentaires ou de supprimer un répertoire qui n'est plus nécessaire.
Il permettra également aux développeurs de créer et de modifier des fichiers de code (lire HTML, PHP et autres). Mais, il n'autorisera toujours l'accès en lecture seule que pour tout le monde.