Dans / etc / group, quelle est la signification du deuxième champ?


18

Un exemple de /etc/groupfichier contient les entrées suivantes:

root:*:0:
adm:!:4:logcheck
antoine:x:1000:

Les pages de manuel que j'ai lues (Debian et OSX) indiquent que le deuxième champ est de stocker un mot de passe de groupe. Comme ils sont rarement utilisés, un astérisque *ou un xest généralement placé dedans plutôt que de le laisser vide.

La shadowpage de manuel indique également que ce deuxième champ doit stocker le résultat de la cryptfonction. Et si un résultat invalide est stocké (comme *ou !), cela signifie que le mot de passe ne peut pas être utilisé comme méthode d'authentification.

Cela vaut-il également pour le groupfichier? Pourquoi est-ce que je me retrouve avec 3 caractères différents dans mon groupfichier ayant tous la même signification? Puis-je tout changer en toute sécurité *?


Que feriez-vous en les changeant tous *?
jordanm

Je ne vois que l' !utilisation d'un seul groupe sur un seul serveur sur 10+ que je gère actuellement. Pour la simplicité de certains scripts de vérification, le fait d'avoir toujours le même caractère clarifierait les choses. Eh bien, si cela signifie en fait la même chose, bien sûr.
Tonin

Réponses:


28

Vous pensez que le !, *ou xa une signification particulière ici, et craignez donc qu'il puisse y avoir une distinction entre eux.

Le fait est que ces personnages sont choisis simplement parce qu'ils se démarquent, au moins aux yeux occidentaux. Ces caractères désignent une valeur manquante, un cas d'exception ou un avertissement. Vous pourriez mettre boogaboogaici et avoir exactement le même effet.

Cela est dû à la façon dont les mots de passe sont traités sur les systèmes de type Unix. Lorsque le système reçoit une entrée de mot de passe, il la hache et la compare au hachage stocké. Par conséquent, tout ce qui importe ici est que vous utilisez un caractère ou une séquence de caractères qui ne peut pas être un hachage de mot de passe valide. (Il ne doit pas non plus inclure de deux points, pour des raisons évidentes.)

Bien qu'il n'y ait aucune différence entre ces personnages du point de vue du système d'exploitation principal, il existe certaines conventions:

  • Quand le pwconv(8)programme Linux voitx , cela signifie que «j'ai déjà déplacé ce hachage de mot de passe public vers le fichier de mot de passe caché».

    Ce n'est pas un cas important dans la pratique, car les jours de la conversion vers (ou, le ciel vous aide, depuis ) les mots de passe cachés sont maintenant derrière nous.

  • Si vous utilisez usermod -Lou passwd -lpour verrouiller un utilisateur, cela !a une signification particulière /etc/shadowcar c'est la convention pour "casser ce hachage pour qu'il ne corresponde plus".

    L'ajout de tout autre caractère au hachage stocké le briserait tout aussi bien. La violation de cette convention empêche simplement usermod -Uou passwd -ude déverrouiller la connexion de l'utilisateur. Tout aussi vrai, puisque vous l'avez verrouillé à la main en ajoutant un faux personnage, vous pouvez le déverrouiller à la main en le supprimant.

    Cependant, tout cela n'est que trivial en ce qui concerne cette question. Il n'y a pas groupmod -Lou gpasswd -ldonc pas de !convention/etc/group .

    Plus Anecdote: si vous êtes allez aux comptes utilisateur de verrouillage à la main, vous devez rester à l' écart de l' [A-Za-z0-9/\]ensemble, puisque ce sont des caractères juridiques pour le hachage. C'est une des raisons d' usermodutiliser !ici au lieu de x.

Je ne vois rien de mal à normaliser tous vos /etc/groupchamps de mot de passe, si cela vous fait vous sentir mieux. Ce faisant, vous dites déjà que vous êtes heureux de pirater ces fichiers à la main, vous n'êtes donc probablement pas du genre à utiliser les outils qui se soucient des distinctions de toute façon. Quoi qu'il en soit, le changement n'aura pas d'effet sur le fonctionnement quotidien du système.


Merci pour votre réponse très complète. Écrivant actuellement des scripts pour vérifier les utilisateurs et les groupes sur mes serveurs, je voulais également savoir si un autre caractère ou séquence de caractères pouvait être trouvé dans ce champ. D'après votre réponse et les détails pas si triviaux, j'ai une bien meilleure vue à ce sujet. Merci encore!
Tonin

1
Pour les scripts, vous devriez probablement appeler getpwent(3)et amis. Perl a des wrappers pour ceux-ci dans sa bibliothèque standard, comme tout autre langage de script axé sur les administrateurs système Unix. Si vous utilisez une langue sans de tels wrappers, ce serait une bonne excuse pour échanger. :)
Warren Young

Si vous lisez encore des choses qui ont presque six ans ... Merci pour la réponse, je vois certaines des raisons historiques pour lesquelles les gens utilisent des choses comme xet *pour marquer un champ de mot de passe "inutilisé". Juste curieux cependant ... la page de manuel indique que le champ peut très bien être laissé vide (ce qui dans le champ de la base de données peut être appelé NULL - en particulier dans Oracle qui définit NULL et la chaîne vide comme étant la même). Donc, revenons à / etc / group: pourquoi utiliser xou !ou *, au lieu de simplement laisser le champ vide? Deux deux points consécutifs se distinguent aussi bien que n'importe lequel de ces personnages. Pas important - juste curieux
mathguy

1
@mathguy: Un champ de mot de passe vide signifie "pas de mot de passe", pas la même chose qu'un champ de mot de passe contenant un caractère qui ne peut jamais correspondre à un vrai mot de passe. Comme la plupart des systèmes Unix n'utilisent pas de mots de passe de groupe, c'est une distinction sans différence, mais vous ne voudriez pas développer une habitude qui vous causera des ennuis, comme avec la plupart des systèmes Linux /etc/shadow. De plus, je rejette l'idée qu'un double colon est tout aussi clair. Vite, combien de champs vides sont là :::::::? Maintenant combien :x:*:!:x:*::? Même nombre de deux points, mais des réponses différentes, j'espère.
Warren Young
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.