Après avoir regardé la gestion des utilisateurs et des groupes par défaut sur certaines distributions Linux habituelles (respectivement ArchLinux et Debian), je me pose deux questions à ce sujet et sur les conséquences de la modification de l'installation et de la configuration par défaut.

La valeur par défaut de USERGROUPS_ENABin /etc/login.defssemble être "yes", ce qui est reflété par le "Par défaut, un groupe sera également créé pour le nouvel utilisateur" qui peut être trouvé dans l' useraddhomme, donc chaque fois qu'un nouvel utilisateur est créé, un Le groupe est créé avec le même nom et uniquement ce nouvel utilisateur. Y a-t-il une utilité ou est-ce juste un espace réservé?

J'ai l'impression que nous perdons une partie de la gestion des droits en tant qu'utilisateur / groupe / autres en faisant cela. Serait-il mauvais d'avoir un groupe "utilisateurs" ou "habitués" ou tout ce que vous voulez l'appeler qui est le groupe par défaut pour chaque utilisateur au lieu d'avoir le leur?

Deuxième partie de ma question, qui est toujours basée sur ce que j'ai vu sur Arch et Debian: il y a beaucoup d'utilisateurs créés par défaut (FTP, HTTP, etc.). Y a-t-il une utilité ou existe-t-il uniquement pour des raisons historiques?

Je pense à les supprimer mais je ne veux pas casser quoi que ce soit qui pourrait l'utiliser, mais je n'ai jamais rien vu faire ainsi, et je n'ai aucune idée de ce qui pourrait. Il en va de même pour les groupes par défaut (tty, mem, etc.) auxquels je n'ai jamais vu aucun utilisateur appartenir.

Groupes par utilisateur

Moi aussi, je ne vois pas beaucoup d'utilité dans les groupes par utilisateur. Le cas d'utilisation principal est que si un utilisateur souhaite autoriser l'accès "amis" à ses fichiers, il peut faire ajouter l'utilisateur ami à son groupe. Peu de systèmes que j'ai rencontrés l'utilisent de cette façon.

Lorsque USERGROUPS_ENABin /etc/login.defsest défini sur "non", useraddajoute tous les utilisateurs créés au groupe défini dans /etc/default/useraddle GROUPchamp. Sur la plupart des distributions, ce paramètre est défini sur le GID 100qui correspond généralement au usersgroupe. Cela vous permet d'avoir une gestion plus générique des utilisateurs. Ensuite, si vous avez besoin d'un contrôle plus fin, vous pouvez ajouter manuellement ces groupes et y ajouter des utilisateurs qui ont du sens.

Groupes créés par défaut

La plupart d'entre eux sont venus de raisons historiques, mais beaucoup ont encore des utilisations valables aujourd'hui:

• disque est le groupe qui possède la plupart des périphériques de lecteur de disque
• lp possède un port parallèle (et est parfois configuré pour les droits d'administrateur sur les cups)
• uucp possède souvent des ports série (y compris des ports série USB)
• cdrom est requis pour les privilèges de montage sur un lecteur de cd
• Certains systèmes utilisent la roue pour les droits sudo; certains non
• etc.

D'autres groupes sont utilisés par les scripts d'arrière-plan. Par exemple, mangénère des fichiers temporaires et autres lors de son exécution; son processus utilise le groupe man pour certains de ces fichiers et se nettoie généralement après lui-même.

Selon la spécification Linux Standard Base Core cependant, seuls 3 utilisateurs qui sont root, bin et daemon sont absolument obligatoires . La raison d'être des autres groupes est la suivante:

La spécification d'utilisateurs et de groupes facultatifs a pour but de réduire le risque de conflits de noms entre les applications et les distributions.

Il semble donc préférable de maintenir ces groupes en place. Il est théoriquement possible de les supprimer sans rupture, bien que pour certains, les choses "mystérieuses" peuvent commencer à ne pas fonctionner correctement (par exemple, certaines pages de manuel ne s'affichent pas si vous tuez ce groupe, etc.). Cela ne fait aucun mal de les laisser là-bas, et on suppose généralement que tous les systèmes Linux en auront.

Question 1: Raisonnement pour le même utilisateur et le même groupe

Bonjour, je suis ecyoung et vous êtes horgix. Nous allons travailler tous les jours et nous connectons au même serveur Linux que les programmeurs. Un jour, il n'y a pas longtemps, notre administrateur système a décidé de faciliter la création et la maintenance des utilisateurs, il a donc désactivé l' USERGROUPS_ENABoption et placé tous les utilisateurs existants dans le nouveau usersgroupe.

Cela a facilité la création d'utilisateurs, mais pas la maintenance, car tous les utilisateurs peuvent accéder à tous les autres fichiers des utilisateurs. Dans un cadre d'entreprise, c'est un grand non non en raison de choses comme Sarbanes Oxley et la séparation des tâches . Si je crée le fichier A, le bit de groupe est défini sur le groupe d'utilisateurs, ce qui signifie que tous les utilisateurs peuvent au moins lire le fichier A. Si l'administrateur système est paresseux, dans certains cas, tous les utilisateurs peuvent RW fichier A. Cela vainc Sarbanes Oxley et SoD parce que les départements séparés ne devraient pas être capables de lire et encore moins d'écrire le document d'autres personnes.

Avec l'utilisateur / le groupe activé si je crée un document en tant que ecyoung, seul j'ai les droits rwx sur celui-ci. Comme personne d'autre n'est dans mon groupe, lorsqu'ils ouvrent mon document, ils voient une page vierge avec un avertissement. Cela applique Sarbanes-Oxley et SoD. Si j'invite d'autres utilisateurs, ces utilisateurs sont autorisés à accéder à rw, et ce faisant, je sais que ce qu'ils voient ne reviendra pas me mordre, ni eux. Comme d'autres l'ont dit, si à la maison, cette séparation peut ne pas être importante pour vous. Si vous déterminez cela, vous pouvez désactiver l'option en toute sécurité et tous les utilisateurs seront ajoutés à un usersgroupe avec un GID de 100. Voir la question 2 ci-dessous.

Hypothétique :
vous travaillez dans l'informatique et Louis travaille dans la paie. Louis conserve la feuille d'impôt et de paie dans son répertoire personnel, mais vous êtes tous les deux dans le groupe d'utilisateurs, vous ouvrez donc son répertoire personnel car il est marqué + r pour les utilisateurs et trouvez sa feuille de calcul. Vous trouverez le montant de votre salaire, ainsi que celui de Joe et de Fred. Pensez-vous que Joe et Fred aimeraient que vous connaissiez leur salaire ??

Question 2: ID de groupe de 0 à 500

Les ID de groupe et inversement les ID utilisateur 0 - 500 sont réservés aux comptes système et à l'accès aux appareils. Voir le tableau des groupes de systèmes préconfigurés pour la liste des comptes standard. Veuillez ne pas supprimer ces comptes à la main. Par exemple, si vous souhaitez supprimer le ftp utilisateur, supprimez le démon ftp avec votre système de gestion de packages. Cela supprimera également le compte système. Les services système comprennent, sans s'y limiter:

• Le service d'impression CUPS
• Le démon du serveur MySQL
• Le démon du serveur FTP
• Le serveur Web Apace
• Le socket X Server pour les connexions à distance
• Le démon ALSA Sound System
• Le service DBUS

Il y en a d'autres, donc si d'autres lecteurs souhaitent ajouter ou supprimer de la liste des services ci-dessus, veuillez le faire.

Si nous partageons tous un groupe par défaut, comme autrefois, nous devons définir notre umask sur 077 pour bloquer le groupe. Si la valeur par défaut est moi, je peux définir le umask sur 027, maintenant si je définis un répertoire de fichiers sur un groupe partagé, ce groupe peut lire. Je n'ai pas non plus à me soucier des modes.

Ce n'est qu'un exemple, mais en général, c'est un moyen de désactiver les groupes, jusqu'à ce que vous en ayez besoin, d'une manière qui les rend plus faciles à activer et à gérer.

Les groupes par utilisateur vous permettent d'avoir à la fois une "confidentialité dans votre répertoire personnel" ainsi qu'une "collaboration facile dans des dossiers partagés". Sans groupes par utilisateur, vous pouvez avoir l'un ou l'autre, mais pas les deux. Les détails suivent:

Unix est un système multi-utilisateurs, qu'il s'agisse d'un serveur de fichiers d'entreprise ou d'un PC avec 2 utilisateurs. La "confidentialité dans votre répertoire personnel" peut être réalisée de plusieurs manières:

Définissez "umask 077" pour que les fichiers soient créés avec rw pour vous et sans autorisations pour les autres. Alternativement, 027 ou 022 afin que certains ou tous puissent lire mais pas écrire vos fichiers. L'inconvénient évident est que vous ne pouvez pas collaborer dans un dossier partagé car les autres ne peuvent pas travailler sur les fichiers que vous créez là-bas en raison d'autorisations strictes. Vous pouvez modifier les autorisations sur ces fichiers, mais c'est "trop ​​de travail" et souvent oublié.

Pour collaborer, vous voulez quelque chose comme "umask 7" afin que vous et le groupe propriétaire puissiez lire et écrire les fichiers que vous créez. C'est idéal pour les dossiers partagés et les groupes composés de toutes les personnes qui ont besoin d'un accès partagé. Mais vous perdez la confidentialité de votre dossier personnel!

Le groupe par utilisateur est la solution! Vous utilisez umask 7, donc tous les fichiers que vous créez sont "rw pour vous et rw pour le groupe". Les fichiers de votre répertoire personnel sont créés avec votre groupe personnel en tant que "groupe propriétaire", donc personne d'autre ne peut accéder à ces fichiers malgré l'autorisation "group rw". Parce que personne d'autre que vous ne fait partie de ce groupe particulier.

Vous pouvez toujours collaborer dans des dossiers partagés. Les fichiers du dossier partagé obtiennent "rw" pour le groupe propriétaire et l'administrateur système configure le dossier partagé de sorte qu'un groupe partagé (appelé collaborateurs) soit le propriétaire du groupe pour les fichiers qui s'y trouvent. Cela se fait en créant ce groupe de collaborateurs, avec tous les utilisateurs collaborateurs en tant que membres. Ensuite, l'administrateur définit la propriété du groupe du dossier partagé sur «collaborateurs» et définit l'autorisation SETGID pour le dossier partagé. Avec SETGID activé, tout ce qui est créé dans le dossier partagé obtiendra le même propriétaire de groupe que le dossier partagé, c'est-à-dire le groupe "collaborateurs". Et avec umask 7 (ou alternativement 2), les membres de ce groupe auront tous un accès en lecture + écriture et pourront ainsi collaborer.

À l'origine, les processus Unix pouvaient appartenir à un groupe à la fois (il y avait une chgrp(1)commande, demandant le mot de passe du groupe stocké dans le champ de mot de passe résiduel dans /etc/groups). Les systèmes Plus ont été utilisés par un groupe restreint d'utilisateurs. Il était logique d'avoir tout le monde dans le usersgroupe et de partager des éléments à l'échelle du système par des autorisations de groupe. Pas de réel souci de sécurité, peu de suspicion d'une dizaine de collègues. Tout était local, sur la même machine. Aucun réseau pour partager des trucs, par exemple via un blog ou autre.

Les systèmes Unix d'aujourd'hui comptent des centaines d'utilisateurs, les exigences de sécurité sont plus strictes et les utilisateurs (et processus) peuvent appartenir à plusieurs groupes. Donnez à chacun des utilisateurs (les plus désemparés) un groupe résidentiel et autorisez-vous à vous en éloigner pour le partager. Ou utilisez des listes de contrôle d'accès.