La raison pour laquelle cela est autorisé aujourd'hui, c'est simplement parce que le système ne l'empêche pas.
Si cela changeait, les systèmes où les administrateurs pouvaient utiliser cette fonctionnalité seraient brisés (voir l'exemple de Terdon). Donc, cela n'a jamais été changé, et je ne pense pas que ce sera le cas.
À l'origine, il n'y avait que les fichiers passwd et group, et ils servaient leur objectif. il n'y avait pas de commande adduser , ni addgroup , les fichiers ont été édités par root à l'aide de vi ou ed.
Il y avait quelques bizarreries!
Afin de se souvenir du prochain identifiant utilisateur à utiliser, il était courant que les administrateurs aient un utilisateur spécial sur la dernière ligne ayant un nom d'utilisateur égal à !(car !c'était un nom d'utilisateur non valide) et cette entrée était utilisée pour stocker la prochaine. identifiant d'utilisateur. Brut, je l'avoue, mais ça a fonctionné! Alors, pourquoi casser les entrailles en les rendant plus compliquées, ce qui s'apparente aujourd'hui au développement agile.
Il y avait des défauts connus. Le principal étant qu’il devait être lisible par tout le monde, afin que des utilitaires comme ceux ls-ci puissent cartographier 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 Unix et la plupart des utilisateurs se contentaient donc de l'édition manuelle.
Il a fallu plusieurs années avant que le shadowfichier de mots de passe ne soit inventé, ce qui a apporté un peu plus de sécurité en masquant les mots de passe cryptés. Encore une fois, juste assez de complexité a été ajoutée, mais c'était quand même assez brut et simple. Les utilitaires useraddet groupaddont été introduits, qui conservés shadowet shadow-mis à jour. Pour commencer, il s’agissait souvent de simples wrappers de scripts shell concernant les utilitaires propriétaires d’ adduser / addgroup des fournisseurs. Encore une fois, c'était juste suffisant pour continuer.
Les réseaux d'ordinateurs grandissaient, les gens travaillaient plusieurs fois à la fois pour faire le travail. L'administration des passwd/groupfichiers était en train de devenir un cauchemar, en particulier avec NFS. C'est ainsi que les Pages Jaunes, également appelées NIS, allaient alléger le fardeau.
Il devenait maintenant évident qu’il fallait quelque chose d’un peu plus souple, et PAM a été inventé. Donc, si vous étiez vraiment sophistiqué et que vous vouliez un système d’authentification centralisé, sécurisé, avec un identifiant unique, appelez un serveur central pour s’authentifier, par exemple un serveur Radius, un serveur LDAP ou Active Directory.
Le monde avait grandi. Mais les fichiers passwd / group / shadow restaient toujours pour nous, utilisateurs / développeurs / laboratoires plus petits. Nous n’avions toujours pas vraiment besoin des cloches et des sifflets. J'imagine que la philosophie avait un peu changé: "Si vous deviez l'améliorer, vous ne l'utiliseriez pas du tout" , alors ne vous inquiétez pas.
C'est pourquoi je ne pense pas que le fichier passwd simple changera jamais. Cela n'a plus sa raison d'être, et il est tout simplement génial pour les Raspberry Pi à 30 £ avec une température de surveillance de 2, voire 3 utilisateurs, et des flux Twitter. OK, vous devez juste être un peu prudent avec vos identifiants si vous voulez qu'ils soient uniques, et rien n'empêche le passionné d'envelopper useradd dans un script qui sélectionne d'abord le prochain identifiant unique d'une base de données (fichier) pour définir un paramètre. identifiant unique, si c'est ce que vous voulez. Il est open source après tout.