Comment configurer les permissions linux pour le dossier WWW?


69

Résumé mis à jour

Le répertoire / var / www est la propriété de root:rootce 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 résoudre ce problème.

Seules deux entités ont besoin d'un accès.

  1. PHP / Perl / Ruby / Python ont tous besoin d'accéder aux dossiers et aux fichiers car ils en créent beaucoup (c'est-à-dire /uploads/). Ces langages de script devraient fonctionner sous nginx ou apache (ou même quelque chose comme FastCGI pour PHP).

  2. Les développeurs

Comment ont-ils accès? Je sais que quelqu'un, quelque part, a déjà fait cela auparavant. Cependant, avec des milliards de sites Web, on pourrait penser 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. Cela ne semble donc pas nécessaire, car il donne aux utilisateurs aléatoires des autorisations complètes.

Quelles sont les autorisations à utiliser /var/wwwpour que:

  1. Contrôle de source tel que git ou svn
  2. Utilisateurs appartenant à un groupe tel que "sites Web" ( ou même ajoutés à "www-data" )
  3. Des serveurs comme Apache ou Lighthttpd
  4. Et PHP / Perl / Ruby

tous peuvent lire, créer et exécuter des fichiers (et des répertoires) là-bas?

Si je ne me trompe pas, les scripts Ruby et PHP ne sont pas "exécutés" directement, mais transmis à un interpréteur. Il n’est donc pas nécessaire d’exécuter une autorisation sur les fichiers dans /var/www...? Par conséquent, il semble que la bonne permission serait celle chmod -R 1660qui ferait

  1. tous les fichiers partageables par ces quatre entités
  2. tous les fichiers non exécutables par erreur
  3. bloquer tout le monde du répertoire entièrement
  4. définir le mode d'autorisation sur «collant» pour tous les fichiers futurs

Est-ce correct?

Mise à jour 1: Je viens de me rendre compte que les fichiers et les répertoires peuvent nécessiter des autorisations différentes - je parlais des fichiers ci-dessus, donc je ne suis pas sûr de ce que les autorisations de répertoire devraient être.

Mise à jour 2: la structure de dossiers des /var/wwwmodifications est drastique, car l’une des quatre entités ci-dessus ajoute toujours (et parfois supprime) des dossiers et des sous-dossiers à plusieurs niveaux. Ils créent et suppriment également des fichiers pour lesquels les 3 autres entités peuvent 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'entre eux ne devrait avoir besoin d'une permission d'exécution (voir la question à propos de ruby ​​/ php ci-dessus), je suppose que cette rw-rw-r--permission suffirait et qu'elle était totalement sûre, ces quatre entités étant gérées par un personnel de confiance (voir n ° 2) et par tous les autres utilisateurs. le système n'a qu'un accès en lecture.

Mise à jour 3: Ceci concerne les machines de développement personnel et les serveurs de sociétés privées. Pas de "clients Web" aléatoires comme un hôte partagé.

Mise à jour 4: Cet article de slicehost semble être le meilleur moyen d’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 OU svn / git est exécuté et comment le modifier.

Mise à jour 5: J'ai enfin (je pense) 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. Par conséquent, j'ai commencé une prime. La personne qui dispose de la meilleure méthode pour sécuriser et gérer le répertoire www gagne.

Réponses:


47

Après plus de recherches, il semble qu’une autre (éventuellement une meilleure façon) de répondre 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/ afin que les développeurs puissent y travailler
  3. sudo chmod -R 2774 /var/www/site.com/ de sorte que seuls les développeurs peuvent créer / éditer des fichiers (other / world peut lire)
  4. sudo chgrp -R www-data /var/www/site.com/uploads de sorte que www-data (apache / nginx) puisse créer des téléchargements.

Dans la gitmesure où cet utilisateur l’appelle, il doit pouvoir créer des dossiers, éditer des fichiers PHP et gérer le référentiel git tant que cet utilisateur appartient au groupe "développeurs".

Remarque: à l'étape (3): «2» sur 2774 signifie «définir l'ID de groupe» pour le répertoire. Ainsi, les nouveaux fichiers et sous-répertoires créés hériteront 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


Cela me semble raisonnable.
Wazoox

Bien. Peut-être que si je peux confirmer cela avec quelques autres personnes, j'utiliserai cette approche. Il semble que ce soit la meilleure réponse que j'ai pu écarter des gens.
Xeoncross

Vous ne spécifiez pas qui serait le propriétaire des fichiers. Voulez-vous le laisser en tant que root? Alors seulement les sudoers peuvent éditer votre dossier de téléchargements (probablement pas ce que vous vouliez).
Nic

Oui, root resterait le propriétaire. Cependant, puisque le propriétaire du groupe est maintenant "développeur" (et dispose de l'autorisation wrx), tous les développeurs (et apache / nginx) peuvent également les lire. Pas besoin de sudo.
Xeoncross

7
Une dernière chose à surveiller est umask. Avec un umask par défaut de 022, de nombreux systèmes suppriment les autorisations d'écriture pour le groupe et le public sur les nouveaux fichiers. Je suppose que vous voulez 002 (pas d'écriture publique) ou 007 (pas d'accès public). Vous pouvez définir l'umask dans la configuration d'Apache et / ou les scripts de démarrage pour tout processus nécessitant un accès au répertoire. N'oubliez pas d'ajouter ceci à / etc / profile ou à / etc / bashrc pour qu'il soit également défini par défaut pour vos développeurs
Mark Porter

8

Je ne sais pas si c'est "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 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 propriétaire du groupe de tous les fichiers et dossiers du répertoire.
  • Le propriétaire de tous les fichiers ou dossiers qui doivent être écrits sur le serveur Web (c'est-à-dire PHP) est remplacé par www-data, l'utilisateur sous lequel s'exécute apache.

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


Comment git / svn ou PHP crée-t-il de nouveaux dossiers?
Xeoncross

2
PHP s'exécute dans le même contexte utilisateur que le serveur Web. Il peut donc créer des fichiers et des dossiers dans tout 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 de git / svn - pouvez-vous les ajouter au compte du groupe qui contrôle le site Web?
Nic

Apparemment, git fonctionne comme l'utilisateur qui l'exécute, comme n'importe quel autre outil.
Xeoncross

Ajoutez ensuite l'utilisateur git au groupe apache et accordez des autorisations d'écriture au groupe de dossiers.
David Rickman

Je viens de dire que git n'a pas d'utilisateur - il fonctionne comme l'utilisateur actuel qui l'utilise.
Xeoncross

7

Après avoir fait plus de recherches, il semble que git / svn TOOLS ne pose pas de problème, car ils fonctionnent 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 répertorié, /usr/bince qui correspond à cette thèse.

Les permissions de Git sont résolues.

Les autorisations des utilisateurs semblent pouvoir être résolues en ajoutant tous les utilisateurs ayant besoin d'accéder au répertoire www au www-datagroupe sous lequel s'exécutent apache (et nginx).

Il semble donc qu’une réponse à cette question se présente comme suit:

Par défaut, /var/wwwappartient à root:rootet personne ne peut y ajouter ou modifier des fichiers.

1) Changer le propriétaire du groupe

Nous devons d’abord changer le groupe de répertoires www qui appartient au groupe "www-data" au lieu du groupe "racine"

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) répertoire www de CHMOD

Modifiez les autorisations de sorte que SEUL le propriétaire (racine) et tous les utilisateurs du groupe "www-data" puissent rwx (lire / écrire / exécuter) des fichiers et des répertoires ( personne d'autre ne devrait pouvoir même 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 (par exemple 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?


6
Je n'aime pas l'idée d'avoir tous les fichiers Web enregistrables avec PHP, cela augmente votre exposition possible en cas de vulnérabilité de script.
Nic

Ok, bien, je sais que j'utilise PHP pour créer beaucoup de fichiers texte, tar, journaux et images (ainsi que des dossiers), donc je partais du principe que tout devrait être accessible en écriture. Cependant, peut-être que votre droit et PHP devraient pouvoir uniquement CHANGER LES FICHIERS QU'ILS CRÉENT, ce qui serait sans danger puisque 99% des applications PHP ne créent jamais de fichiers de script. L’autre choix semble être de n’autoriser que certains répertoires avec un accès en écriture PHP (/ uploads /), ce qui n’en fait pas, car PHP pourrait toujours être utilisé pour créer quelque chose de mauvais. Des idées?
Xeoncross

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

6

La rigidité n'est pas l'héritage des autorisations. La rigidité 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, et ce, même si les autorisations le permettent. Ainsi 1777 sur / tmp /.

Sous Unix classique, il n'y a pas d'héritage d'autorisations basé sur le système de fichiers, mais uniquement sur le processus en cours umask. Sous * BSD ou Linux avec setgid dans le répertoire, le champ groupe des fichiers nouvellement créés sera identique à celui du répertoire parent. Pour tout autre avantage, vous devez vous pencher sur les ACL, avec la liste de contrôle d'accès «par défaut» sur les répertoires, ce qui vous permet d'avoir des autorisations héritées.

Commencez par définir: * quels utilisateurs ont accès au système * quel est votre modèle de menace

Par exemple, si vous hébergez plusieurs clients sur Internet et que vous ne voulez pas qu'ils voient les fichiers de chacun, vous pouvez utiliser un groupe commun "webcusts" pour tous ces utilisateurs et un mode de répertoire de 0705. Ensuite, les fichiers fournis par le processus du serveur Web ( pas dans "webcusts") verra les autres perms et sera autorisé; les clients ne peuvent pas voir les fichiers les uns des autres et les utilisateurs peuvent jouer avec leurs propres fichiers. Cependant, cela signifie que dès que vous autorisez CGI ou PHP, vous devez 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 hôte, pour la responsabilité). Sinon, les clients pourraient avoir des problèmes avec les fichiers des autres en faisant appel à un CGI.

Toutefois, si l'utilisateur au moment de l'exécution pour un site Web est identique à son propriétaire, vous ne pouvez pas protéger le contenu contre les auteurs d'abus 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 plus avoir à vous soucier de l’interaction avec d’autres utilisateurs.


Bonne réponse. Sous MacOS X, le système se comporte comme si le bit SGID se trouvait automatiquement dans les répertoires. Le bit collant signifie généralement que vous ne pouvez supprimer le fichier que si vous pouvez l'écrire. Autrement dit, n'importe qui peut supprimer un fichier accessible en écriture publique dans / tmp. Sur 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.
Jonathan Leffler

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

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 qu'il doit agir dès qu'il est entré dans le répertoire 'fichier'). Les autorisations sur le fichier individuel n'entrent pas en jeu pour ces opérations de répertoire ( rename(), unlink()), uniquement pour les actions sur le fichier lui-même ( open()). C'est le comportement "habituel".
Phil P

2

Je pense que la meilleure façon de procéder consiste à utiliser les ACL 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


+1 pour les informations utiles sur les ACL. Cependant, je ne veux pas que de la corbeille supplémentaire enlève du temps au système pour gérer un simple serveur avec quelques développeurs. De plus, je ne suis pas à l'aise avec la recompilation du noyau pour pouvoir utiliser les ACL.
Xeoncross

@Xeoncross: les ACL ne s'enlisent pas. Ce ne sont que des métainformations similaires aux autorisations de fichiers normales. Ce n’est pas tout ce qui est "extra" et compliqué, je pense que c’est le moyen le plus simple et le meilleur de gérer les autorisations, plutôt que de créer une solution complexe, collante, de groupe ou quelconque. Ne soyez pas effrayé, remontez avec acl et essayez!
Tie-fighter

1

Le propriétaire du fichier doit être la personne qui le crée, tandis que le groupe doit être www-data. Le mode pour les 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 est 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 {} \;

0

En ajoutant à la réponse de @ Xeoncross, je pense qu’il serait bien de configurer les autorisations sur les fichiers et les répertoires séparément.

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 pourraient avoir besoin de créer des répertoires supplémentaires ou de supprimer un répertoire devenu inutile.

Cela permettra également aux développeurs de créer et de modifier des fichiers de code (lire du HTML, des fichiers PHP, etc.). Mais, n'autorisera toujours qu'un accès en lecture seule pour tous les autres.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.