Comment configurer les permissions linux pour le dossier WWW?

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.

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

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.

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?

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.

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

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 {} \;

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.