Warum kann ich Benutzer mit derselben UID erstellen?

Mein Verständnis von UIDs ist, dass es sich um eine eindeutige positive Ganzzahl handelt, die jedem Benutzer von einem Unix-ähnlichen Betriebssystem zugewiesen wird. Jeder Benutzer wird durch seine UID gegenüber dem System identifiziert, und Benutzernamen werden im Allgemeinen nur als Schnittstelle für Menschen verwendet.

Wie können zwei Benutzer dieselbe UID haben, ist dies kein Konflikt für mein System und meine Pakete?

root@kdc:~# id test12
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~# id test13
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~#

Ich habe zwei Benutzer mit derselben UID und GID hinzugefügt: test12und test13

Die Ausgabe von /etc/passwd:

client@kdc:~$ cat /etc/passwd | grep test12
test12:x:1005:1000::/home/test12:/bin/sh
client@kdc:~$ cat /etc/passwd | grep test13
test13:x:1005:1000::/home/test13:/bin/sh

Ich habe die Benutzer von hinzugefügt useradd -ou 1005 -g1000 username.

Ich war verwirrt, wozu das dient, und kann es sich auf Berechtigungen und Benutzerprotokolle usw. auswirken. Also, wenn ein Benutzer hinzugefügt wird uid=0und gid=0Berechtigungen wie ein Root-Konto hat?

Die Antwort hier ist, dass Linux Sie nicht vor sich selbst schützt.

Wenn Sie wirklich su rootin die / etc-Dateien gehen und allen Benutzern die gleiche UID geben möchten , können Sie dies tun. Es ist nur eine Textdatei.

Aber du solltest es wirklich nicht und es wird unbeabsichtigte Konsequenzen haben.

Dafür gibt es tatsächlich triftige Gründe. Ich habe zum Beispiel in einem Labor gearbeitet, in dem jeder seinen eigenen Computer hatte, aber $HOMEsich in einem freigegebenen Laufwerk befand, das von einem Server exportiert wurde. Also, meine $HOMEwar

/users/terdon

Da sich der /usersOrdner tatsächlich nicht auf meinem lokalen Computer befand, sondern über NFS exportiert wurde, verwendete ich für jede Analyse, die E / A-Probleme mit sich brachte, Daten, die auf meinen lokalen Festplatten gespeichert waren, um das Netzwerk des Labors nicht zu belasten. Zu diesem Zweck hatte ich und alle anderen zwei Benutzer: einen für das gesamte System und einen für die betreffende Maschine. Das Haus des lokalen Benutzers war

/home/localuser

Allerdings musste ich vollen Zugriff auf meine Dateien haben , ob ich als angemeldet war terdonoder wie localuserund die Art und Weise unsere Sysadmin umgesetzt hatten , die , indem sie beide war localuserund terdondie gleiche UID. Auf diese Weise konnte ich meine lokalen Dateien frei bearbeiten, unabhängig davon, als welcher Benutzer ich gerade angemeldet war.

Zwei Benutzer können dieselbe UID haben, da es sich nur um eine Zahl in einer Textdatei handelt, sodass Sie sie auf einen beliebigen Wert festlegen können, einschließlich eines bereits verwendeten Werts. Wie Sie jedoch gesehen haben, ist dies keine gute Idee.

Eigentlich ist es ziemlich üblich, zwei Benutzer mit derselben ID zu haben. Unter FreeBSD gibt es normalerweise zwei Benutzer mit der UID 0: root und toor. Root verwendet die integrierte / bin / sh-Shell und toor verwendet eine andere Shell, normalerweise bash.

Unix-Systeme und Linux tun im Allgemeinen nichts, um Duplikate in der /etc/passwdDatei zu verhindern. Mit dieser Datei soll eine UID mit einem physischen Namen verknüpft werden, der von Befehlszeilentools angezeigt werden kann, z. B. lswenn der Benutzer Dateien auflistet.

$ ls -n | head -5
total 986000
drwxrwxr-x.   3 1000 1000      4096 Feb 13 19:51 1_archive_sansa
-rw-rw-r--.   1 1000 1000    760868 Dec 16 08:21 2.18.x Database Scheme.jpg
-rw-rw-r--.   1 1000 1000       972 Oct  6 20:26 abcdefg
drwxrwxr-x.   2 1000 1000      4096 Feb 11 03:34 advanced_linux_programming

Der andere Zweck dieser Datei besteht darin, anzugeben, welche Shell ein Benutzer erhält, wenn er sich anmeldet.

$ getent passwd saml
saml:x:1000:1000:saml:/home/saml:/bin/bash

Ein üblicher Angriffsvektor bei Unix-Systemen besteht darin, der Systemdatei folgende Zeilen hinzuzufügen /etc/passwd:

$ getent passwd r00t
r00t:x:0:0:root:/root:/bin/bash

$ getent passwd toor
toor:x:0:0:root:/root:/bin/bash

Die Rolle der /etc/passwdDatei ist NICHT dazu gedacht, nur Benutzerkonten zu verfolgen. Die Rolle der Verfolgung von Benutzernamen und Passwörtern liegt in der Verantwortung der /etc/shadowDatei. Dateien wie /etc/passwdund /etc/groupsollen wirklich einen lesbaren Namen liefern, wenn Ihr System Dateien von Datenträgern auflistet.

Denken Sie daran, dass Ihre Dateien unter Verwendung von UID / GIDs, die keine tatsächlichen Namen sind, auf die Festplatte geschrieben werden.

$ stat afile 
  File: ‘afile’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd02h/64770d    Inode: 6560621     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    saml)   Gid: ( 1000/    saml)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2014-02-27 15:54:21.852697029 -0500
Modify: 2014-02-27 15:54:21.852697029 -0500
Change: 2014-02-27 15:54:21.852697029 -0500
 Birth: -

Beachten Sie die Uid:und Gid:, die Zahlen sind, was tatsächlich auf die Festplatte geschrieben!

Unter Linux sind alle Benutzer und Gruppen nur Zahlen. Das zeigt die Ausgabe des von idIhnen geposteten Befehls.

Die /etc/passwdDatei ordnet Benutzernamen an Benutzer - IDs (Zahlen) und im Beispiel haben Sie bieten, Sie haben einfach zwei Benutzernamen auf die gleiche Benutzer - ID zugeordnet.

Tatsächlich haben Sie einen Benutzer mit der test12ID 1005 erstellt, der auch einen zweiten Benutzernamen hat test13. Das System ordnet jedoch die UID 1005 dem ersten Benutzernamen zu, den es findettest12

Linux "lässt" Sie dies tun, weil es kein System gibt, das Sie daran hindert, dies zu tun. /etc/passwdIst nur eine Textdatei. Benutzernamen werden der UID zugeordnet, die für ihren Eintrag in dieser Datei gefunden wurde. UIDs werden dem ersten Benutzernamen zugeordnet, der in dieser Datei gefunden wurde.

Aber was Sie erstellt haben, ist eine verwirrende Situation für andere Systemadministratoren. Vermeiden Sie dies, indem Sie die UID von änderntest13

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.

Die /etc/passwdDatei ordnet nur symbolische Benutzernamen der realen Benutzer-ID zu. Wenn Sie absichtlich zwei symbolische Namen eingeben, die einer Benutzer-ID zugeordnet sind, können Sie dies tun.

Das bedeutet nicht, dass es eine gute Idee ist, es tatsächlich zu tun. Einige Benutzer haben möglicherweise sehr spezielle Anwendungsfälle gefunden, in denen sie diese Funktion nutzen können. Im Allgemeinen sollten Sie dies jedoch nicht tun.

Linux (und andere UNIXe) sind der Meinung, dass der Administrator weiß, was sie tun. Wenn du sagst, dass du etwas Dummes tun sollst, ist das deine eigene Schuld. Genauso wie wenn du deinem Auto sagst, dass es über eine Klippe fahren soll, kannst du nicht zu den Herstellern gehen und fragen, warum das Auto dir das erlaubt hat.

Es gibt Bezeichner, von denen das Betriebssystem erwartet, dass sie eindeutig sind, sie werden jedoch zum Nachverfolgen von Hardware verwendet. Das Wissen, dass ein bestimmter Universally Unique IDentifier einer Festplatte mit Systemdateien entspricht, kann dazu beitragen, den Betrieb fortzusetzen, wenn sich die Hardwarekonfiguration ändert. Microsoft nennt diese Globally Unique IDentifiers und verwendet sie, um die gesamte Windows-Software zu verfolgen. Ironischerweise wurden diese Akronyme schlecht gewählt.

Aus Sicht des Betriebssystems ändern sich die meisten Benutzer- und Gruppen-IDs in etwa an der äußeren Oberfläche. Es könnte trotz Kollisionen normal funktionieren; Von den Systembenutzern und -gruppen wird hauptsächlich verlangt, dass sie existieren. Es kann nicht wissen, was die Benutzer benötigen. In solchen Situationen ist die Unix-Philosophie, dass das Betriebssystem davon ausgehen sollte, dass die Administratoren wissen, was sie tun, und ihnen dabei helfen sollten, dies schnell zu tun.

Ich habe Beweise gefunden, die @ andybalholms Antwort stützen.

Aus APUE , §8.15:

Jeder Prozess kann seine tatsächliche und effektive Benutzer- und Gruppen-ID ermitteln. Manchmal möchten wir jedoch den Anmeldenamen des Benutzers herausfinden, der das Programm ausführt. Wir könnten getpwuid( getuid()) aufrufen , aber was ist, wenn ein einzelner Benutzer mehrere Anmeldenamen mit jeweils derselben Benutzer-ID hat? ( Eine Person hat möglicherweise mehrere Einträge in der Kennwortdatei mit derselben Benutzer-ID, um für jeden Eintrag eine andere Anmeldeshell zu haben .) Das System verfolgt normalerweise den Namen, unter dem wir uns anmelden (Abschnitt 6.8), und die getloginFunktion bietet eine Möglichkeit um diesen Anmeldenamen abzurufen.

....

Mit dem angegebenen Anmeldenamen können wir dann den Benutzer in der Kennwortdatei suchen, um beispielsweise die Anmeldeshell zu bestimmen getpwnam.

Übrigens würde ich gerne wissen, ob man während des Logins zu einer anderen Shell wechseln kann.