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


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

Nous avons deux utilisateurs réguliers et root. Alors, quand vous jouez avec 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.


211
2018-05-11 05:13


origine


Regarde aussi: Quelles sont les meilleures autorisations linux à utiliser pour mon site web? - Zoredache


Réponses:


Tenter d'élargir @ Zoredache réponse, comme je le fais 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'identifiant du 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 y a un -R option récursive, mais cela ne fera pas la distinction entre les fichiers et les dossiers, de sorte que vous devez utiliser find, ainsi:

    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 umask ligne au bas de /etc/profile dans mon cas) signifie que les fichiers créés par un utilisateur seront inscriptibles par d’autres utilisateurs du groupe www sans avoir à chmod leur.

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!


201
2017-09-15 05:11



@Tom Excellent de voir que vous recommandez d'utiliser le findcommande pour cela. Un petit conseil de performance que je vous donnerais si vous avez beaucoup de fichiers / répertoires et que vous utilisez GNU find, c'est d'utiliser + au lieu de \; de sorte que la commande sera opérer sur plusieurs fichiers parce que "Il est plus rapide d’exécuter une commande sur autant de fichiers que possible à la fois, plutôt qu’une seule fois par fichier. Cela permet d’économiser le temps nécessaire au démarrage de la commande à chaque fois." En outre, il est plus facile de taper car il n’a pas besoin de barre oblique inverse. - aculich
Mise à jour avec la suggestion de @ aculich d'utiliser + not \; - Tom
@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
@ 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
Ok, donc par usera et userb tu veux dire www-data et ftpuser ? J'ai trouvé cela très déroutant avec toute mention de www-data, qui était dans la question initiale. Aussi, quel est le but / avantage de mettre le propriétaire à root? Devrions-nous le régler sur ftpuser? - gskema


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 se trouve 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, je mettrais en place quelque chose de plus complexe.


59
2018-05-11 05:49



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 pour 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
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 autorisations octales, les masques masqués, etc. Quelques exemples de commandes illustrant votre approche seraient grandement appréciés. - Tom
De cette façon, chaque utilisateur peut accéder aux fichiers de tous les autres utilisateurs! Cela signifie que l’utilisateur A peut lire config.php de l’utilisateur B ... lui dérobant ses informations de connexion mysql, par exemple - drAlberT
En utilisant acl, vous pouvez gérer à la fois la sécurité et la collaboration :) - drAlberT


Je pense que vous pouvez trouver les ACL POSIX (listes de contrôle d’accès) utiles. 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" d'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


39
2018-05-11 16:26



C'est le chemin ! +1 - drAlberT
ACL pour la victoire +1 ... Pour plus voir serverfault.com/a/360120/41823 - Yarin
Je me demande s’il existe un inconvénient en termes de performances pour les autorisations ACL par rapport aux autorisations de base. - Buttle Butkus
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 excellent 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-data par 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 de module / 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 d'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


Cette question était demandé à nouveau, et comme discuté En ce qui concerne Meta, les meilleures pratiques actuelles fournissent de meilleures approches que celles disponibles en 2009, lorsque cela a été demandé. Cette réponse tente de donner quelques solutions actuelles pour 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 servent pas tous les sites utilisant www-data. C’est important, car aujourd’hui, 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 la Le plus commun langue du site du serveur, 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.

  • Utilisation Protocole de transfert de fichiers SSH (SFTP). 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 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 à la ~/.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 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 mot de passe.

  • Utiliser PHP-FPM. C'est l'approche actuelle pour utiliser PHP en tant qu'utilisateur. Créer un nouveau bassin pour chaque utilisateur, à savoir 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 unique peut consommer.

    Voir par exemple NeverEndingSecurity's Exécutez php-fpm avec un utilisateur / uid distinct et un groupe sur linux. Il y a des tutoriels comme HowtoForge Utiliser PHP-FPM avec Apache sur Ubuntu 16.04 cela n'utilise pas PHP-FPM pour renforcer la sécurité grâce à la séparation des utilisateurs, ce qui incite à utiliser un seul socket FPM sur le serveur.


7
2018-05-10 10:03