Der Grund, warum dies heute erlaubt ist, ist einfach, weil das System es nicht verhindert.
Wenn sich dies ändert, werden die Systeme beschädigt, auf denen Administratoren diese Funktion verwendet haben (siehe Terdons Beispiel). Es wurde also nie geändert, und ich glaube nicht, dass dies jemals der Fall sein wird.
Ursprünglich gab es nur die Dateien passwd und group, und sie erfüllten ihren Zweck. es gab keinen adduser- befehl, keine addgroup , die dateien wurden von root mit vi oder ed bearbeitet.
Es gab ein paar Macken!
Um sich die nächste zu verwendende Benutzer-ID zu merken, war es üblich, dass Administratoren einen speziellen Benutzer als letzte Zeile hatten, der den Benutzernamen !(weil !ein ungültiger Benutzername war) hatte, und dieser Eintrag wurde zum Speichern der nächsten verwendet Benutzeridentifikation. Roh, ich gebe zu, aber es hat funktioniert! Warum sollte man also einen Bauch aufmachen, der es komplizierter macht, ähnlich wie die heutige agile Entwicklung?
Es gab bekannte Mängel. Das Hauptkriterium war, dass es weltweit lesbar sein musste, damit Versorgungsunternehmen wie es lsabgebildet werden konnten user-id => name. Dies bedeutete, dass jeder das verschlüsselte Passwort von jedem sehen konnte und alle Benutzer und IDs im System.
Einige Unix-Systeme führten ein paar Shell-Skripte ein adduser addgroup, die oft ignoriert wurden, weil sie zwischen Unixen inkonsistent waren, sodass die meisten Leute nur mit der manuellen Bearbeitung weitermachten.
Es dauerte einige Jahre, bis die shadowKennwortdatei erfunden wurde. Dies bot ein wenig mehr Sicherheit, da die verschlüsselten Kennwörter ausgeblendet wurden. Auch hier wurde gerade genug Komplexität hinzugefügt, aber es war immer noch ziemlich grob und einfach. Die Utilities useraddund groupaddwurden vorgestellt, welche gepflegt shadowund shadow-aktualisiert wurden. Zu Beginn handelte es sich häufig um einfache Shell-Skript-Wrapper für herstellereigene Dienstprogramme adduser / addgroup . Wieder war es gerade genug, um weiterzumachen.
Computernetzwerke wuchsen, Menschen arbeiteten an mehreren Arbeitsplätzen gleichzeitig, so dass die Verwaltung der passwd/groupDateien zu einem Albtraum wurde, vor allem mit NFS. Gelbe Seiten, auch als NIS bekannt, trugen zur Entlastung bei.
Inzwischen wurde klar, dass etwas Flexibleres erforderlich war und PAM erfunden wurde. Wenn Sie also hochentwickelt wären und ein zentrales, sicheres und eindeutig identifizierbares Authentifizierungssystem benötigen, wenden Sie sich zur Authentifizierung an einen zentralen Server, z. B. einen Radius-Server, einen LDAP-Server oder ein Active Directory.
Die Welt war erwachsen geworden. Aber die passwd / group / shadow-Dateien blieben für uns kleinere Benutzer / Entwickler / Labs. Wir haben immer noch nicht wirklich alles verlangt. Ich denke, die Philosophie hatte sich inzwischen ein wenig geändert: "Wenn du es besser machen würdest, würdest du es überhaupt nicht benutzen" , also mach dir keine Sorgen.
Aus diesem Grund glaube ich nicht, dass sich die einfache passwd-Datei jemals ändern wird. Es hat keinen Sinn mehr, und es ist einfach großartig für die £ 30 Raspberry Pi's mit 2 oder 3 Überwachungstemperaturen und Twitter-Feeds. OK, Sie müssen nur ein wenig vorsichtig mit Ihren Benutzer-IDs sein, wenn Sie sie eindeutig haben möchten, und nichts hindert den Enthusiasten daran, useradd in ein Skript zu schreiben, das zuerst die nächste eindeutige ID aus einer Datenbank (Datei) auswählt , um eine festzulegen eindeutige ID, wenn es das ist, was Sie wollen. Es ist doch Open Source.