Quel est le meilleur moyen de gérer les autorisations pour l'utilisateur www-data d'Apache 2 dans / var / www?


215

Quelqu'un at-il une bonne solution pour gérer les fichiers /var/www? Nous utilisons des hôtes virtuels nommés et l’utilisateur d’Apache 2 est www-data .

Nous avons deux utilisateurs réguliers et root. Donc, lorsque vous manipulez des fichiers /var/www, plutôt que d'avoir à ...

chown -R www-data:www-data

... tout le temps, quel est un bon moyen de gérer cela?

Question complémentaire: À quel point les autorisations sont-elles optimales?

Celui-ci a toujours été un problème dans les environnements de développement collaboratif.


Réponses:


206

Essayer d'élargir la réponse de @ Zoredache , alors que j'essaye moi-même:

  • Créer un nouveau groupe (www-pub) et ajouter les utilisateurs à ce groupe

    groupadd www-pub

    usermod -a -G www-pub usera ## doit utiliser -a pour ajouter aux groupes existants

    usermod -a -G www-pub userb

    groups usera ## groupes d'affichage pour l'utilisateur

  • Changez la propriété de tout ce qui est sous / var / www en root: www-pub

    chown -R root:www-pub /var/www ## -R pour récursif

  • Modifier les autorisations de tous les dossiers sur 2775

    chmod 2775 /var/www ## 2 = définir l'identifiant du groupe, 7 = rwx pour le propriétaire (racine), 7 = rwx pour le groupe (www-pub), 5 = rx pour le monde (y compris l'utilisateur Apache www-data)

    Définir l'ID de groupe ( SETGID ) bit (2) entraîne la copie du groupe (www-pub) dans tous les nouveaux fichiers / dossiers créés dans ce dossier. Les autres options sont SETUID (4) pour copier l’identifiant de l’utilisateur et STICKY (1) qui, je pense, permet uniquement au propriétaire de supprimer des fichiers.

    Il existe une -Roption récursive, mais qui ne fait pas de distinction entre les fichiers et les dossiers, vous devez donc utiliser find , comme ceci:

    find /var/www -type d -exec chmod 2775 {} +

  • Changer tous les fichiers en 0664

    find /var/www -type f -exec chmod 0664 {} +

  • Changez le umask pour vos utilisateurs en 0002

    Umask contrôle les autorisations de création de fichier par défaut. 0002 signifie que les fichiers auront 664 et les répertoires 775. Ce paramètre (en modifiant la umaskligne au bas de /etc/profilemon cas) signifie que les fichiers créés par un utilisateur seront accessibles en écriture par d'autres utilisateurs dans le répertoire www- groupe sans avoir besoin d' chmodeux.

Testez tout cela en créant un fichier et un répertoire et en vérifiant le propriétaire, le groupe et les autorisations avec ls -l.

Remarque: vous devrez vous déconnecter / vous connecter pour que les modifications apportées à vos groupes prennent effet!


6
@Tom Excellent de voir que vous recommandez d'utiliser la findcommande pour cela. Un petit conseil sur les performances que je donnerais si vous avez beaucoup de fichiers / répertoires et que vous utilisez GNU find: utilisez +plutôt que de \;sorte que la commande fonctionne sur plusieurs fichiers car "il est plus rapide d’exécuter une commande sur autant de fichiers que possible Une fois par fichier, pas une fois. Cela permet de gagner du temps pour lancer la commande à chaque fois. " En outre, il est plus facile de taper car il n’a pas besoin de barre oblique inverse.
Aculich

2
Mise à jour avec la suggestion de @ aculich d'utiliser + not \;
Tom

1
@SunnyJ. essayez ceci (sans les guillemets extérieurs): "find / var / www -type f -exec chmod 0664 '{}' \ +" Essayez. Il y a un espace entre le '{}' et le \ +.
Buttle Butkus

1
pourquoi nous devons donner la permission aux autres de voir et d’exécuter.
Kevin Parker

1
@ Tom- way pour le décomposer, merci. Juste une remarque - je pense que "SETUID (4) pour copier l'identifiant de l'utilisateur" tel qu'inclus dans votre réponse est erroné - SETUID est ignoré lorsqu'il est appliqué à des répertoires sous Linux / Unix - Ref
Yarin

60

Je ne sais pas trop comment vous voulez configurer les autorisations, mais cela peut vous donner un point de départ. Il y a probablement de meilleurs moyens. Je suppose que vous voulez que les deux utilisateurs puissent changer n'importe quoi dans / var / www /

  • Créez un nouveau groupe (www-pub) et ajoutez les utilisateurs à ce groupe.
  • Changez la propriété de tout ce qui est sous / var / www en root: www-pub.
  • Modifier les autorisations de tous les dossiers sur 2775
  • Remplacez tous les fichiers par 0664.
  • Changez le umask pour vos utilisateurs en 0002

Cela signifie que tout nouveau fichier créé par l'un de vos utilisateurs doit être un nom d'utilisateur: www-pub 0664 et tout répertoire créé doit être un nom d'utilisateur: www-pub 2775. Apache obtiendra un accès en lecture à tout via le composant "autres utilisateurs". Le bit SETGID sur les répertoires forcera tous les fichiers en cours de création à appartenir au groupe propriétaire du dossier. Vous devez ajuster umask pour vous assurer que le bit d’écriture est défini de sorte que tout membre du groupe puisse éditer les fichiers.

Quant à savoir comment je vais sur les permissions. Cela dépend complètement du site / serveur. S'il n'y a que 1 ou 2 rédacteurs et que je dois juste les empêcher de tout casser, je vais y aller doucement. Si l'entreprise nécessitait quelque chose de plus complexe, j'organiserais quelque chose de plus complexe.


1
Ajout possible - définissez les répertoires de cache / téléchargement sur lesquels le serveur Web doit écrire sur www-data: www-data et 775.
gacrux

Est-ce que cela fonctionnerait aussi d'ajouter les utilisateurs au groupe apache au lieu de s'appuyer sur des autorisations "autres"? Si vous ne faites que télécharger des fichiers et que ces fichiers doivent être lisibles par Apache, un troisième groupe ne semble utile que si vous devez modifier ces fichiers.
Simurr

1
Avez-vous une chance d'élargir un peu @Zoredache? Je me familiarise avec l'utilisation de base des bits rwx, chmod, chown, adduser, usermod, mais vous m'avez perdu avec le premier chiffre supplémentaire sur les permissions octales, les masques et tout le reste. Quelques exemples de commandes illustrant votre approche seraient grandement appréciés.
Tom

1
De cette façon, chaque utilisateur peut accéder aux fichiers de tous les autres utilisateurs! Cela signifie que l'utilisateurA peut lire le fichier config.php de l'utilisateurB ... lui volant ses informations d'identification mysql, par exemple
drAlberT

1
En utilisant acl, vous pouvez gérer à la fois la sécurité et la collaboration :)
drAlberT

39

Je pense que vous trouverez peut-être utile les listes de contrôle d'accès POSIX ACL. Ils permettent un modèle d'autorisation plus fin comparé à l'utilisateur: groupe: autre modèle. Je les ai trouvés plus faciles à garder dans ma tête, car je peux être plus explicite et aussi définir le comportement "par défaut" pour une branche du système de fichiers.

Par exemple, vous pouvez spécifier explicitement les autorisations de chaque utilisateur:

setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www

Ou vous pouvez le faire en fonction d'un groupe partagé:

setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www

Et peut-être que vous voulez garder votre utilisateur Apache en lecture seule

setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www

Pages de manuel:

Didacticiel


2
C'est le chemin ! +1
drAlberT

ACL pour la victoire +1 ... Pour en savoir plus, consultez serverfault.com/a/360120/41823
Yarin

1
Je me demande s’il existe un inconvénient en termes de performances pour les autorisations de base ou les autorisations de base.
Buttle Butkus

2
Malheureusement, ACL manque trop souvent sur les installations / distributions standard. C’est pénible de compiler le noyau sur tous les serveurs que je gère, ou pire, de changer parfois de système de fichiers. De plus, vous devez faire très attention lorsque vous sauvegardez des fichiers, en particulier si vous changez de serveur. ACL est génial, mais son support actuel est si bas que je le déconseille à toute personne qui n’a pas le contrôle total sur tout ce qui se trouve sur le serveur et ses environs. Mais +1 pour indiquer à ACL où il fait vraiment sens!
Ninj

Bonne réponse +1; Une note sur la modification des autorisations de lecture / écriture du processus apache ( www-datapar exemple) en lecture seule pour l'ensemble du site (via setfacl ou chmod - ou les deux) -> Ceci bloquera évidemment toutes les écritures (téléchargement / mise à jour du plugin / module depuis le navigateur sur la plupart des CMS par exemple). Je crois que beaucoup de gens populaires testent également l'accès en écriture au niveau de la perm utilisateur, pas au niveau du groupe. Vous pouvez toujours mettre à jour, mais les mises à jour doivent être appliquées manuellement et toutes les autorisations personnalisées pour les dossiers d'écriture (logs / temp / uploads / etc.). La lecture seule est une grande sécurité si votre site fonctionne avec. Dans l’ensemble, la plupart ne le font pas.
bshea

11

Cette question a été à nouveau posée et, comme cela a été discuté dans la méta, les meilleures pratiques actuelles fournissent de meilleures approches qu’elles n’étaient disponibles en 2009, année où cette question a été posée. Cette réponse tente de donner quelques solutions actuelles pour la gestion sécurisée des environnements de développement Web collaboratifs .


Pour un serveur Web sécurisé et un développement collaboratif, il n'y a pas que les autorisations de fichiers:

  • Avoir un utilisateur distinct pour chaque site, c'est-à-dire ne pas desservir tous les sites utilisant www-data. Ceci est important car, de nos jours, Apache ne sert que rarement des fichiers de contenu statiques , mais utilise des sites Web dynamiques . Cette réponse se concentre sur PHP car il s'agit du langage de site de serveur le plus courant , mais les mêmes principes s'appliquent également aux autres.

    Si vous rencontrez un problème de sécurité sur un seul site, celui-ci peut se propager sur tous les sites exécutés sous le même utilisateur. Un attaquant peut voir tout ce que voit l'utilisateur, y compris les informations de connexion à la base de données, et modifier tous les sites pour lesquels l'utilisateur dispose de droits en écriture.

  • Utilisez le protocole SFH ( SSH File Transfer Protocol ). Bien que l'utilisation de FTP doive être abandonnée pour des raisons de sécurité (car elle envoie à la fois les mots de passe et le contenu en texte brut), son substitut sécurisé, SFTP, possède également une fonctionnalité qui constitue une solution parfaite pour le développement Web collaboratif.

    Une fois que vous avez isolé les sites et un utilisateur par site, vous devez donner un accès à vos développeurs Web, en quoi consiste cette question. Plutôt que de leur donner les mots de passe de ces utilisateurs du site - ou d'accéder aux fichiers du site à l'aide de leurs comptes d'utilisateur personnels comme suggéré à l'origine -, vous pouvez utiliser des clés SSH pour vous connecter.

    Chaque développeur peut générer une paire de clés et garder la clé privée secrète. Ensuite, la clé publique est ajoutée au ~/.ssh/authorized_keysfichier pour chaque compte d'utilisateur de site Web sur lequel le développeur travaille. Cela présente de nombreux avantages pour la gestion des mots de passe et des connexions:

    • Chaque développeur peut avoir accès à un nombre illimité de sites Web sans avoir à mémoriser ou stocker tous les mots de passe impliqués dans la configuration utilisateur par site.

    • Pas besoin de changer et de partager les mots de passe à chaque fois que quelqu'un quitte l'entreprise.

    • Vous pouvez utiliser des mots de passe très forts ou désactiver complètement la connexion basée sur un mot de passe.

  • Utilisez PHP-FPM . C'est l'approche actuelle pour exécuter PHP en tant qu'utilisateur. Créez un nouveau pool pour chaque utilisateur, c'est-à-dire un pool pour chaque site. C'est le meilleur pour la sécurité et les performances, car vous pouvez également spécifier la quantité de ressources qu'un site unique peut consommer.

    Voir par exemple Exécuter php-fpm de NeverEndingSecurity avec un utilisateur / uid et un groupe distincts sur linux . Il existe des tutoriels tels que HowtoForge ( Utilisation de PHP-FPM avec Apache sous Ubuntu 16.04) qui n'utilisent pas PHP-FPM pour accroître la sécurité par la séparation des utilisateurs, ce qui vous permet d'utiliser un seul socket FPM sur le serveur.

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.