La raison pour laquelle cela est autorisé aujourd'hui, c'est simplement parce que le système ne l'empêche pas.
Si cela a changé, alors cela casserait les systèmes où les administrateurs ont eu une utilisation de cette fonctionnalité (voir l'exemple de Terdon). Donc, ça n'a jamais été changé, et je ne pense pas que ce sera le cas.
À l’origine, seuls les fichiers passwd et group étaient utilisés. il n'y avait pas de commande adduser , pas de addgroup , les fichiers étaient édités par root en utilisant vi ou ed.
Il y a eu quelques bizarreries!
Afin de se souvenir du prochain identifiant utilisateur à utiliser, il était fréquent que les administrateurs aient un utilisateur spécial comme dernière ligne avec un nom d'utilisateur de ! (car ! était un nom d'utilisateur invalide) et cette entrée était utilisée pour stocker l'ID utilisateur suivant. Crude, je l'avoue, mais ça a marché! Alors, pourquoi se démoniser pour le rendre plus compliqué, semblable à un développement agile aujourd'hui?
Il y avait des défauts connus. L’essentiel étant qu’il soit lisible par tous, de sorte que des utilitaires comme ls puissent mapper user-id => name . Cela signifiait que tout le monde pouvait voir le mot de passe crypté de tout le monde, ainsi que tous les utilisateurs et identifiants du système.
Certains systèmes Unix ont commencé à introduire quelques scripts shell adduser addgroup , souvent ignorés, car ils étaient incohérents entre les Unix, de sorte que la plupart des gens ne faisaient que modifier manuellement.
Il a fallu plusieurs années avant d’inventer le fichier shadow password, ce qui apportait un peu plus de sécurité en masquant les mots de passe chiffrés. Encore une fois, juste assez de complexité a été ajouté, mais il était encore assez grossier et simple. Les utilitaires useradd et groupadd ont été introduits, ce qui a maintenu shadow et shadow- mis à jour. Pour commencer, il s’agissait souvent de simples enveloppes de script shell autour des utilitaires propriétaires adduser / addgroup propriétaires des fournisseurs. Encore une fois, c'était juste suffisant pour continuer.
Les réseaux d’ordinateurs grandissaient, les gens travaillaient sur plusieurs pour obtenir des travaux, donc l’administration des fichiers passwd/group devenait un cauchemar, en particulier avec NFS. alléger le fardeau.
Il devenait évident que quelque chose de plus flexible était nécessaire, et PAM était inventé. Donc, si vous étiez vraiment sophistiqué et que vous vouliez un système d’authentification centralisé, sécurisé, unique et unique, vous appeleriez un serveur central pour vous authentifier, peut-être un serveur Radius, un serveur LDAP ou Active Directory.
Le monde a grandi. Mais les fichiers passwd / group / shadow restaient toujours pour nous, petits utilisateurs / développeurs / laboratoires. Nous n'avions toujours pas vraiment besoin de toutes les cloches et de tous les sifflets. Je suppose que la philosophie a changé un peu maintenant, "Si vous vouliez améliorer les choses, vous ne l'utiliseriez pas du tout" , alors ne vous inquiétez pas.
C'est pourquoi je ne pense pas que le simple fichier passwd changera jamais. Cela ne sert à rien, et c'est tout simplement génial pour les Raspberry Pi de 30 £ avec 2 ou 3 températures de surveillance, et les flux Twitter. OK, vous devez juste être un peu prudent avec vos identifiants d’utilisateur si vous voulez qu’ils soient uniques, et rien n’empêche le passionné d’encapsuler useradd dans un script qui sélectionne d’abord le prochain identifiant unique dans un script. base de données (fichier) pour définir un identifiant unique, si c'est ce que vous voulez. C'est open source après tout.