Quelle est la meilleure façon de gérer les autorisations pour les données www de l'utilisateur d'Apache 2 dans /var/www ?

Solution 1 :

J'essaie de développer la réponse de @Zoredache, alors que j'essaie 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 ajouter aux groupes existants

  usermod -a -G www-pub userb

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

• Changer la propriété de tout ce qui se trouve sous /var/www en root :www-pub

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

• Changez les permissions de tous les dossiers en 2775

  chmod 2775 /var/www ## 2=set group id, 7=rwx for owner (root), 7=rwx for group (www-pub), 5=rx for world (y compris apache www-data user)

  Le bit (2) de définition de l'ID de groupe (SETGID) 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, ne permet qu'au propriétaire de supprimer des fichiers.

  Il y a un -R option récursive, mais cela ne fera pas de distinction entre les fichiers et les dossiers, vous devez donc utiliser 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 {} +

• Changez le umask pour vos utilisateurs en 0002

  Le 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. Paramétrer ceci (en éditant le umask ligne au bas de /etc/profile dans mon cas) signifie que les fichiers créés par un utilisateur seront accessibles en écriture par d'autres utilisateurs du groupe www sans avoir besoin de chmod eux.

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 !

Solution 2 :

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 meilleurs moyens. 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.
• Changez la propriété de tout ce qui se trouve sous /var/www en root:www-pub.
• Changez les permissions de tous les dossiers en 2775
• Changez tous les fichiers en 0664.
• Changez le umask pour vos utilisateurs en 0002

Cela signifie que tout nouveau fichier créé par l'un de vos utilisateurs doit être username:www-pub 0664 et tout répertoire créé sera username: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. L'ajustement de l'umask est nécessaire pour s'assurer que le bit d'écriture est défini afin que n'importe qui dans le groupe puisse modifier les fichiers.

Quant à savoir à quel point je vais sur les autorisations. Cela dépend entièrement du site/serveur. S'il n'y a que 1 ou 2 éditeurs et que j'ai juste besoin de les empêcher de trop casser les choses, je vais y aller doucement. Si l'entreprise avait besoin de quelque chose de plus complexe, je mettrais en place quelque chose de plus complexe.

Solution 3 :

Je pense que vous pouvez trouver POSIX ACL (listes de contrôle d'accès) utile. Ils permettent un modèle d'autorisation plus fin par rapport au modèle utilisateur:groupe:autre. Je les ai trouvés plus faciles à garder dans ma tête puisque je peux être plus explicite et que je peux é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 en fonction d'un groupe partagé :

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

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

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

Pages de manuel :

• setfacl
• getfacl

Tutoriel

Solution 4 :

Cette question a été posée à nouveau, et comme indiqué sur la méta, les meilleures pratiques actuelles offrent de meilleures approches que celles disponibles en 2009, lorsque cette question a été posée. Cette réponse tente de donner quelques solutions actuelles pour gérer en toute sécurité les environnements de développement Web collaboratif .

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 servir tous les sites en utilisant www-data . Ceci est important, car de nos jours, Apache sert rarement uniquement statique fichiers de contenu, mais en cours d'exécution dynamique sites Internet. Cette réponse se concentre sur PHP car c'est le langage de site 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, il peut se propager à tous les sites exécutés par le même utilisateur. Un attaquant peut voir tout ce que l'utilisateur voit, y compris les informations de connexion à la base de données, et modifier chaque site sur lequel l'utilisateur dispose d'autorisations en écriture.

• Utiliser le protocole de transfert de fichiers SSH (SFTP). Bien que l'utilisation de FTP doive être abandonnée pour des raisons de sécurité (car il 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 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é à 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_keys fichier 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 identifiants :

  • Chaque développeur peut avoir accès à n'importe quel nombre de sites Web sans avoir à mémoriser ou à stocker tous les mots de passe impliqués dans l'arrangement 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.

• Utiliser PHP-FPM . C'est l'approche actuelle pour exécuter PHP en tant qu'utilisateur. Créer un nouveau pool pour chaque utilisateur, c'est-à-dire un pool par site. C'est ce qu'il y a de mieux pour la sécurité et les performances, car vous pouvez également spécifier la quantité de ressources qu'un seul site peut consommer.

  Voir par ex. Exécutez php-fpm de NeverEndingSecurity avec un utilisateur/uid et un groupe séparés sur Linux. Il existe des tutoriels comme HowtoForge's Using PHP-FPM with Apache on 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.