77 votes

Comment configurer les permissions linux pour le dossier WWW ?

Résumé actualisé

Le répertoire /var/www appartient à root:root ce qui signifie que personne ne peut l'utiliser et qu'il 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 corriger cela.

Seules deux entités doivent y avoir accès.

  1. PHP/Perl/Ruby/Python ont tous besoin d'accéder aux dossiers et aux fichiers puisqu'ils en créent un grand nombre (ex. /uploads/ ). Ces langages de script doivent être exécutés sous nginx ou apache (ou même quelque chose d'autre comme FastCGI pour PHP).

  2. Les développeurs

Comment y ont-ils accès ? Je sais que quelqu'un, quelque part a déjà fait cela auparavant. Avec les milliards de sites web qui existent, on pourrait penser qu'il y a 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 des autorisations complètes à des utilisateurs aléatoires.

Quelles sont les permissions à utiliser sur /var/www de sorte que :

  1. Contrôle de source comme git ou svn
  2. Les utilisateurs d'un groupe comme "sites web" ( ou même ajouté à "www-data" )
  3. Serveurs comme apache ou lighthttpd
  4. Et PHP/Perl/Ruby

peuvent tous y lire, créer et exécuter des fichiers (et des répertoires) ?

Si je ne me trompe pas, les scripts de Ruby et PHP ne sont pas "exécutés" directement - mais transmis à un interpréteur. Il n'y a donc pas besoin d'autorisation d'exécution pour les fichiers dans le répertoire /var/www ... ? Par conséquent, il semble que l'autorisation correcte serait chmod -R 1660 ce qui rendrait

  1. tous les fichiers partageables par ces quatre entités
  2. tous les fichiers non exécutable par erreur
  3. bloquer entièrement l'accès au répertoire à tous les autres
  4. mettre le mode de permission à "sticky" 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 de permissions différentes - je parlais des fichiers ci-dessus, donc je ne suis pas sûr de ce que les permissions des répertoires devraient être.

Mise à jour 2 : La structure du dossier de /var/www change radicalement car l'une des quatre entités ci-dessus ajoute (et parfois supprime) constamment des dossiers et des sous-dossiers à de nombreux niveaux de profondeur. Elles créent et suppriment également des fichiers auxquels les trois autres entités peuvent avoir besoin d'un accès en lecture/écriture. Par conséquent, les autorisations doivent faire les quatre choses ci-dessus à la fois pour les fichiers et les répertoires. Puisqu'aucun d'entre eux ne devrait avoir besoin de la permission d'exécution (voir la question sur ruby/php ci-dessus), je suppose que rw-rw-r-- une autorisation serait tout ce qui est nécessaire et totalement sûre puisque ces quatre entités sont gérées par 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 est pour les machines de développement personnel et les serveurs d'entreprises privées. Pas de "clients web" aléatoires comme sur 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 permissions pour votre dossier www. Cependant, je ne suis pas sûr de l'utilisateur ou du groupe sous lequel apache/nginx avec PHP OU svn/git fonctionnent 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. C'est pourquoi j'ai lancé un appel d'offres. La personne qui a la meilleure méthode pour sécuriser et gérer le répertoire www gagne.

56voto

Xeoncross Points 4179

Après plus de recherche, il semble qu'une autre (peut-être meilleure) façon de répondre à cette question serait de configurer le dossier www comme suit.

  1. sudo usermod -a -G developer user1 (ajouter chaque utilisateur au groupe de développeurs)
  2. sudo chgrp -R developer /var/www/site.com/ pour que les développeurs puissent y travailler
  3. sudo chmod -R 2774 /var/www/site.com/ pour que seuls les développeurs puissent créer/modifier les fichiers (les autres/monde peuvent lire)
  4. sudo chgrp -R www-data /var/www/site.com/uploads pour que www-data (apache/nginx) puisse créer des téléchargements.

Desde git s'exécute sous le nom de l'utilisateur qui l'appelle, alors tant que l'utilisateur fait partie du groupe "developer", il devrait pouvoir créer des dossiers, éditer des fichiers PHP et gérer le dépôt git.

Note : A l'étape (3) : 2" dans 2774 signifie "définir l'ID du groupe" pour le répertoire. Ainsi, les nouveaux fichiers et sous-répertoires créés dans le répertoire héritent de l'ID de groupe du répertoire parent (au lieu du groupe primaire de l'utilisateur) : http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories

0 votes

Ça me semble raisonnable.

0 votes

Bien. Si je peux le confirmer avec quelques autres personnes, j'utiliserai peut-être cette approche. C'est la meilleure réponse que j'ai pu obtenir des gens.

0 votes

Vous ne précisez pas qui serait le propriétaire des fichiers. Voulez-vous le laisser en tant que root ? Dans ce cas, seuls les sudoers peuvent modifier votre dossier uploads (ce qui n'est probablement pas votre intention).

9voto

DaRKoN_ Points 4098

Je ne suis pas sûr que ce soit "correct", 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 dans le 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 groupe propriétaire de tous les fichiers et dossiers du répertoire.
  • Tous les fichiers ou dossiers qui doivent être écrits par le serveur web (par exemple PHP) ont leur propriétaire changé en www-data, l'utilisateur sous lequel Apache fonctionne.

N'oubliez pas que le bit d'exécution doit être activé sur les répertoires pour que vous puissiez en lister le contenu.

0 votes

Comment git/svn ou PHP créent-ils alors de nouveaux dossiers ?

2 votes

PHP fonctionne dans le même contexte utilisateur que le serveur web, il peut donc créer des fichiers et des dossiers dans n'importe quel répertoire appartenant au serveur web. Il n'y a généralement que quelques dossiers comme celui-ci (/uploads/ par exemple). Je ne suis pas sûr pour git/svn - pourriez-vous les ajouter au compte de groupe qui contrôle le site Web ?

0 votes

Apparemment, git fonctionne comme l'utilisateur qui l'exécute - comme tout autre outil.

8voto

Xeoncross Points 4179

Après avoir fait plus de recherches, il semble que git/svn OUTILS ne sont PAS un problème puisqu'ils s'exécutent sous le nom de l'utilisateur qui les utilise. (Cependant, les démons git/svn sont une autre affaire !) Tout ce que j'ai créé/cloné avec git avait mes permissions et l'outil git était listé dans le répertoire /usr/bin qui correspond à cette thèse.

Permissions Git résolues.

Les permissions des utilisateurs semblent pouvoir être résolues en ajoutant tous les utilisateurs qui ont besoin d'accéder au répertoire www à la liste des utilisateurs de l'annuaire. www-data sous lequel apache (et nginx) s'exécutent.

Il semble donc que une réponse à cette question est la suivante :

Par défaut /var/www est détenu par root:root y personne peut y ajouter ou modifier des fichiers.

1) Changer le propriétaire du groupe

Tout d'abord, nous devons changer le groupe du répertoire www pour qu'il appartienne au groupe "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 n'importe qui d'autre) au groupe www-data

sudo usermod -a -G www-data demousername

3) CHMOD répertoire www

Changez les permissions de sorte que SEUL le propriétaire (root) et tous les utilisateurs du groupe "www-data" puissent rwx (lire/écrire/exécuter) les fichiers et les répertoires ( Personne d'autre ne devrait pouvoir y accéder. ).

sudo chmod -R 2770 /var/www

Maintenant, tous les fichiers et répertoires créés par n'importe quel utilisateur qui y a accès (c'est-à-dire dans le groupe "www-data") seront lisibles/inscriptibles par apache et donc par php.

Est-ce correct ? Qu'en est-il des fichiers que PHP/Ruby créent - les utilisateurs de www-data peuvent-ils y accéder ?

6 votes

Je n'aime pas l'idée d'avoir tous les fichiers web accessibles en écriture par PHP, cela augmente votre exposition possible s'il y a une vulnérabilité script.

0 votes

Ok, je sais que j'utilise PHP pour créer des tas de texte, tar, log, et image (plus les dossiers) donc je supposais que tout devait être accessible en écriture. Cependant, peut-être que vous avez raison et que PHP devrait être capable de seulement MODIFIER LES FICHIERS QU'IL CRÉE ce qui serait inoffensif puisque 99% de toutes les applications PHP ne font jamais de fichiers script. L'autre choix semble être de n'autoriser l'accès en écriture de PHP qu'à certains répertoires (/uploads/), ce qui n'est pas logique car PHP pourrait alors être utilisé pour créer quelque chose de mauvais à cet endroit. Des idées ?

2 votes

Essayez de séparer le script et les données. Même si un attaquant parvient à déposer quelque chose dans /uploads/, cela ne devrait pas être exécutable. La sécurité en couches est la clé.

7voto

Phil P Points 3020

L'adhérence n'est pas un héritage de permissions. 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, même si les permissions disent le contraire. Ainsi, 1777 sur /tmp/.

Dans l'Unix classique, il n'y a pas d'héritage de permissions basé sur le système de fichiers, seulement sur l'umask du processus en cours. Sous *BSD, ou Linux avec setgid sur le répertoire, le champ groupe des fichiers nouvellement créés sera défini comme celui du répertoire parent. Pour toute autre chose, vous devez vous pencher sur les ACL, avec l'ACL 'par défaut' sur les répertoires, qui vous permet d'avoir des permissions héritées.

Vous devriez 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 des autres, vous pouvez utiliser un groupe commun "webcusts" pour tous ces utilisateurs et un mode de répertoire de 0705. Ensuite, les fichiers servis par le processus du serveur web ( no dans "webcusts") verront les autres perms et seront autorisés ; les clients ne peuvent pas voir les fichiers des autres et les utilisateurs peuvent manipuler leurs propres fichiers. Cependant, cela signifie qu'à partir du moment où vous autorisez CGI ou PHP, vous ont pour s'assurer que les processus s'exécutent en tant qu'utilisateur spécifique (bonne pratique de toute façon, pour les utilisateurs multiples sur un seul hôte, pour la responsabilité). Sinon, les clients pourraient s'introduire dans les fichiers des autres en demandant à un CGI de le faire.

Cependant, si l'utilisateur d'exécution d'un site Web est le même que le propriétaire du site, vous avez des problèmes avec l'impossibilité de protéger le contenu contre les abuseurs dans le cas d'une 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 les autres utilisateurs.

0 votes

Bonne réponse. Sous MacOS X, le système se comporte automatiquement comme si le bit SGID était sur les répertoires. Le bit sticky signifie généralement que vous ne pouvez supprimer le fichier que si vous pouvez l'écrire. Autrement dit, tout le monde peut supprimer un fichier accessible en écriture publique dans /tmp. Sous MacOS X, /tmp est un lien symbolique vers un répertoire privé pour l'utilisateur - il n'y a donc pas de partage après tout.

0 votes

Merci pour la réponse, j'ai mis à jour la question avec plus d'informations.

0 votes

Jonathan : le bit collant signifie que seul le propriétaire du répertoire, ou le propriétaire du fichier, peut le renommer ou le supprimer (c'est-à-dire agir sur son entrée dans le répertoire 'file'). Les permissions sur le fichier individuel n'entrent pas en jeu pour ces opérations sur le répertoire ( rename() , unlink() ), uniquement pour les actions sur le fichier lui-même ( open() ). C'est le comportement "habituel".

3voto

Tie-fighter Points 741

Je pense que la meilleure façon de procéder est d'utiliser les ACL Posix. Elles sont faciles à utiliser et offrent toutes les fonctionnalités dont vous avez besoin.

http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs

0 votes

+1 pour les informations utiles sur les ACL. Cependant, je ne veux pas que des déchets supplémentaires embourbent le système juste pour gérer un simple serveur avec un couple de développeurs. Je ne suis pas non plus à l'aise avec la recompilation du noyau afin d'utiliser les ACL.

0 votes

@Xeoncross : Les ACLs ne bloquent rien. Elles ne sont que des méta-informations comme les autorisations normales de fichiers. Ce n'est pas si "extra" et compliqué, je crois que c'est la façon la plus simple et la meilleure de gérer les permissions plutôt qu'une solution confuse de type sticky/groupe/quelque chose. N'ayez pas peur, remontez simplement avec acl et essayez !

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X