it-swarm-eu.dev

Quelle est la meilleure façon de gérer les autorisations des utilisateurs www-data d'Apache 2 dans / var / www?

Quelqu'un at-il une solution intéressante pour gérer les fichiers dans /var/www? Nous exécutons des hôtes virtuels basés sur le nom et l'utilisateur Apache 2 est www-data.

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

chown -R www-data:www-data

... tout le temps, quelle est la bonne façon de gérer cela?

Question supplémentaire: Dans quelle mesure allez-vous ensuite sur les autorisations?

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

218
Gareth

Tenter de développer sur @ Zoredache's réponse , comme je le fais moi-même:

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

    groupadd www-pub

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

    usermod -a -G www-pub userb

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

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

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

  • Modifiez les autorisations de tous les dossiers à 2775

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

    Définir l'ID de groupe ( SETGID ) le 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'ID utilisateur et STICKY (1) qui, je pense, ne laisse que le propriétaire supprimer les fichiers.

    Il y a un -R option récursive, mais qui ne fera pas de distinction entre les fichiers et les dossiers, vous devez donc tiliser find , comme ceci:

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

  • Changez tous les fichiers en 0664

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

  • Remplacez le umask de vos utilisateurs par 0002

    L'umask contrôle les autorisations de création de fichiers par défaut, 0002 signifie que les fichiers auront 664 et les répertoires 775. Définissez cela (en modifiant la ligne umask au bas de /etc/profile dans mon cas) signifie que les fichiers créés par un utilisateur seront accessibles en écriture par les autres utilisateurs du groupe www sans avoir besoin de chmod.

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!

209
Tom

Je ne sais pas exactement comment vous souhaitez configurer les autorisations, mais cela peut vous donner un point de départ. Il existe probablement de meilleures façons. Je suppose que vous voulez que les deux utilisateurs puissent changer quoi que ce soit sous/var/www /

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

Cela signifie que tout nouveau fichier créé par l'un de vos utilisateurs doit être nom d'utilisateur: www-pub 0664 et tout répertoire qui sera créé sera 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 créés à appartenir au groupe propriétaire du dossier. Il est nécessaire d'ajuster le umask pour s'assurer que le bit d'écriture est défini de sorte que n'importe qui dans le groupe puisse éditer les fichiers.

Quant à la façon dont je suis hardcore sur les autorisations. Cela dépend complètement du site/serveur. S'il n'y a que 1-2 éditeurs et que j'ai juste besoin de les empêcher de trop casser les choses, alors j'irai doucement. Si l'entreprise avait besoin de quelque chose de plus complexe, je créerais quelque chose de plus complexe.

62
Zoredache

Je pense que vous pouvez trouver POSIX ACL (listes de contrôle d'accès) pour être utile. Ils permettent un modèle d'autorisation plus fin par rapport à 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 peut également 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 sur la base 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:

Tutoriel

39
Joe Holloway

Cette question était posée à nouvea , et comme discutée sur la méta, les meilleures pratiques actuelles offrent de meilleures approches que celles disponibles en 2009, lorsque cela a été demandé. Cette réponse essaie de donner quelques solutions actuelles pour gérer les environnements de développement Web collaboratifs en toute sécurité .


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

  • Avoir un utilisateur distinct pour chaque site c'est-à-dire ne pas servir tous les sites en utilisant www-data. Ceci est important, car de nos jours Apache ne sert que rarement uniquement des fichiers de contenu statique, mais exécute des sites Web dynamique. Cette réponse se concentre sur PHP car c'est la langue la plus courante du site du serveur, mais les mêmes principes s'appliquent également aux autres.

    Si vous avez un problème de sécurité sur un seul site, il peut se propager à chaque site qui s'exécute en tant que 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 chaque site sur lequel l'utilisateur dispose de droits d'écriture.

  • Utilisez SSH File Transfer Protocol (SFTP). Lors de l'utilisation de FTP, il faut abandonner pour des raisons de sécurité (car il envoie à la fois le mots de passe et le contenu en texte brut), son substitut sécurisé SFTP a également une fonctionnalité qui est 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 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 en utilisant leurs comptes d'utilisateurs personnels comme suggéré initialement - vous pouvez utiliser clés SSH pour la connexion.

    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_keys fichier pour chaque compte 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 à n'importe quel nombre de sites Web sans avoir à se souvenir 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 par 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 par 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 peut consommer.

    Voir par exemple NeverEndingSecurity's Exécutez php-fpm avec un utilisateur/uid et un groupe séparés sur linux . Il existe des tutoriels comme HowtoForge tilisation de PHP-FPM avec Apache sur Ubuntu 16.04 qui n'utilise pas PHP-FPM pour augmenter la sécurité grâce à la séparation des utilisateurs, guidant l'utilisation d'un seul socket FPM sur le serveur.

11
Esa Jokinen