Lösung 1:
Meine Meinung:
Ist diese Fähigkeit so konzipiert oder funktioniert sie einfach so?
Es ist entworfen. Seit ich angefangen habe, *NIX zu verwenden, können Sie Benutzer gemeinsamen Gruppen zuordnen. Die Möglichkeit, die UID ohne Probleme gleich zu haben, ist nur ein beabsichtigtes Ergebnis, das wie alles Probleme verursachen kann, wenn es falsch verwaltet wird.
Wird dies für alle *nix-Varianten konsistent sein?
Ich glaube schon.
Ist das gängige Praxis?
Akzeptiert, wie es allgemein auf die eine oder andere Weise verwendet wird, ja.
Hat diese Praxis unbeabsichtigte Folgen?
Außer Login Auditing haben Sie nichts weiter. Es sei denn, Sie wollten genau das, um damit anzufangen.
Lösung 2:
Funktioniert es auf allen Unixen? Ja.
Ist es eine gute Technik zu verwenden? Nein. Es gibt andere Techniken, die besser sind. Zum Beispiel kann die richtige Verwendung von Unix-Gruppen und streng kontrollierten "sudo"-Konfigurationen dasselbe erreichen.
Ich habe genau einen Ort gesehen, an dem dies ohne Probleme verwendet wurde. In FreeBSD ist es üblich, ein zweites Root-Konto namens "toor" (Root rückwärts geschrieben) zu erstellen, das /bin/sh als Standard-Shell hat. Auf diese Weise können Sie sich immer noch anmelden, wenn die Shell von root durcheinander gebracht wird.
Lösung 3:
Ich kann keine kanonische Antwort auf Ihre Fragen geben, aber anekdotisch macht mein Unternehmen dies seit Jahren mit dem Root-Benutzer und hatte nie Probleme damit. Wir erstellen einen 'kroot'-Benutzer (UID 0), dessen einziger Existenzgrund darin besteht, /bin/ksh als Shell anstelle von /bin/sh oder bin/bash zu haben. Ich weiß, dass unsere Oracle-DBAs etwas Ähnliches mit ihren Benutzern machen, indem sie 3 oder 4 Benutzernamen pro Installation haben, alle mit denselben Benutzer-IDs (ich glaube, dies wurde gemacht, um separate Home-Verzeichnisse für jeden Benutzer zu haben. Wir machen das seit mindestens Zehn Jahre auf Solaris und Linux. Ich denke, es funktioniert wie vorgesehen.
Mit einem normalen Benutzerkonto würde ich das nicht machen. Wie Sie bemerkt haben, geht nach der ersten Anmeldung alles auf den Vornamen in der Protokolldatei zurück, daher denke ich, dass die Aktionen eines Benutzers als die Aktionen eines anderen in Protokollen maskiert werden könnten. Für Systemkonten funktioniert es jedoch hervorragend.
Lösung 4:
Hat diese Praxis unbeabsichtigte Folgen?
Es gibt ein Problem, das mir bekannt ist. Cron spielt mit diesem UID-Aliasing nicht gut. Versuchen Sie, „crontab -i“ von einem Python-Skript aus auszuführen, um Cron-Einträge zu aktualisieren. Führen Sie dann "crontab -e" in der Shell aus, um dasselbe zu ändern.
Beachten Sie, dass cron (ich glaube Vixie) jetzt die gleichen Einträge für a1 und a2 (in /var/spool/cron/a1 und /var/spool/cron/a2) aktualisiert hat.
Lösung 5:
Ist diese Fähigkeit so konzipiert oder funktioniert sie einfach so?
So gestaltet.
Wird dies für alle *nix-Varianten konsistent sein?
Das sollte es, ja.
Ist das gängige Praxis?
Kommt darauf an, was du meinst. Diese Art von Dingen beantwortet ein äußerst spezifisches Problem (siehe root/toor-Konten). Woanders und du fragst nach einem dummen Problem in der Zukunft. Wenn Sie sich nicht sicher sind, ob dies die richtige Lösung ist, ist sie es wahrscheinlich nicht.
Hat diese Praxis unbeabsichtigte Folgen?
Es ist allgemein üblich, Benutzernamen und UIDs als austauschbar zu behandeln. Wie einige andere Leute darauf hingewiesen haben, sind Anmelde-/Aktivitätsprüfungen ungenau. Sie sollten auch das Verhalten aller relevanten benutzerbezogenen Skripte/Programme überprüfen (die useradd-, usermod-, userdel-Skripte Ihrer Distribution, alle regelmäßigen Wartungsskripte usw.).
Was versuchen Sie damit zu erreichen, was nicht erreicht werden würde, wenn Sie diese beiden Benutzer zu einer neuen Gruppe hinzufügen und dieser Gruppe die erforderlichen Berechtigungen erteilen?