Pourquoi les users nouvellement créés sont-ils affectés à des groupes principaux de leurs noms d'user?

J'ai remarqué que sur un certain nombre de dissortingbutions Linux, chaque fois qu'un nouvel user est créé, il est assigné à un groupe primaire de son propre nom.

par exemple. Si je crée un user appelé "testuser", il est affecté par défaut au groupe principal "testuser".

Cela provoque tous les users à avoir leurs propres groupes primaires uniques. Tous ces groupes n'auraient qu'un seul user, car il n'aurait pas vraiment de sens d'append d'autres users à ces groupes. C'est un peu contre-intuitif car "groupe" signifie généralement "plus de 1".

Ces groupes principaux d'users sont également généralement inutiles lorsqu'ils tentent d'atsortingbuer des permissions aux files / dossiers.

Y at-il une raison pour laquelle il s'agit du comportement par défaut sur les dissortingbutions? Et tous les cas d'utilisation où ce comportement est réellement utile? Pourquoi ne pas affecter tous les nouveaux users à un groupe principal "users"?

La raison (la seule raison, pour autant que je sache) de mettre des users dans un groupe à eux-mêmes est de rendre umask 002 ou umask 007 un défaut raisonnable.

L' umask est un masque pour les permissions par défaut des files nouvellement créés. La signification des numbers est la même que dans chmod ; le premier chiffre est pour l'user, le second pour le groupe et le troisième pour les autres. Si un bit est 1 dans l'umask, il est supprimé (masqué) des permissions du nouveau file créé. Par exemple, si une application crée un file non exécutable sans exigence de confidentialité particulière¹, elle passera à 666 en tant qu'permissions de files et l'application de l'umask 002 donnera un file avec les permissions 664 ( 0666 & ~002 dans C- comme la notation), c'est-à-dire un file lisible par tout le monde et inscriptible uniquement par l'user et le groupe ( rw-rw-r-- ).

Avec l'umask 022, les files sont lisibles par le monde par défaut mais seulement en écriture par leur auteur. Avec l'umask 002, les files sont en plus inscriptibles par le groupe qui les possède. Si le groupe principal des users est celui où ils sont le seul user et que l'umask est 002, alors:

  • Par défaut, les files ne sont inscriptibles que par leur auteur, car bien que les droits d' rw-rw-r-- soient rw-rw-r-- , aucun autre user du groupe ne dispose d'permissions en écriture.
  • Pour permettre à un file d'être modifié par les membres d'un groupe, l'auteur doit seulement en faire la propriété de ce groupe avec chgrp . Cela peut même se produire automatiquement si le file est créé dans un directory avec le bit setgid ou une ACL équivalente.

L'avantage sur le masque 022 est que dans ce réglage, pour créer un file modifiable par les users, l'auteur doit faire deux choses: définir le groupe et étendre les permissions ( chmod g+w ). Les gens ont tendance à oublier cette deuxième étape (ou étape unique, dans un directory setgid).

¹ Exemples de files avec des exigences de confidentialité particulières: keys de encryption; courriels; tout file dans un directory public tel que /tmp .

Il était habituel d'append tous les users aux users du groupe, mais cela rend le partage des files maladroit (ouvrir les permissions de groupe, tout le monde a access). Comme aujourd'hui, un process peut appartenir à beaucoup de groupes à la fois, il suffit de fermer l'access en donnant à chaque user son propre groupe, et de partager des files en ajoutant des groupes explicites pour cela. Ou (si disponible) utiliser les ACL .