Pourquoi puis-je créer des utilisateurs avec le même UID?

D'après ce que je comprends des UID, il s'agit d'un entier positif unique attribué à chaque utilisateur par un système d'exploitation de type Unix. Chaque utilisateur est identifié au système par son UID et les noms d'utilisateur ne sont généralement utilisés que comme interface pour les humains.

Comment deux utilisateurs peuvent-ils avoir le même UID, n'est-ce pas un conflit pour mon système et mes packages?

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:~#

J'ai ajouté deux utilisateurs avec les mêmes UID et GID: test12et test13

La sortie de /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

J'ai ajouté les utilisateurs par useradd -ou 1005 -g1000 username.

Je me suis demandé quel était le but de cette opération. Cela peut-il affecter les autorisations, les journaux des utilisateurs, etc. Maintenant, si un utilisateur est ajouté avec uid=0et gid=0aura des privilèges tels qu'un compte root?

La réponse ici est que Linux ne vous protège pas contre vous-même.

Si vous voulez vraiment su rootaller dans les fichiers / etc et donner le même UID à tous les utilisateurs, vous pouvez le faire. C'est juste un fichier texte.

Mais vous ne devriez vraiment pas et cela aura des conséquences inattendues.

Il y a des raisons valables à cela. Par exemple, je travaillais dans un laboratoire où nous avions chacun notre propre ordinateur mais notre ordinateur $HOMEétait dans un lecteur partagé exporté par un serveur. Donc, mon $HOMEétait

/users/terdon

Comme le /usersdossier n'était pas réellement sur ma machine locale mais exporté via NFS, j'utiliserais les données stockées sur mes disques durs locaux pour toute analyse trop chargée en E / S afin de ne pas surcharger le réseau du laboratoire. À cette fin, moi-même et tout le monde, avions deux utilisateurs: un système et un système local pour la machine en question. Le domicile de l'utilisateur local était

/home/localuser

Cependant, je devais avoir un accès complet à mes fichiers, que je sois connecté terdonou non, localuseret la façon dont notre administrateur système l’avait mise en œuvre consistait à donner les deux localuseret terdonle même UID. Ainsi, je pouvais manipuler mes fichiers locaux librement, quel que soit l'utilisateur pour lequel je suis actuellement connecté.

Deux utilisateurs peuvent avoir le même UID car il ne s'agit que d'un nombre dans un fichier texte. Vous pouvez donc le définir comme bon vous semble, y compris une valeur déjà utilisée. Comme vous l'avez vu cependant, ce n'est pas une bonne idée.

Il est en fait assez courant d'avoir deux utilisateurs avec le même identifiant. Sur FreeBSD, il y a généralement deux utilisateurs avec l'UID 0: root et toor. Root utilise le shell / bin / sh intégré et toor utilise un shell différent, généralement bash.

Les systèmes Unix et Linux ne font généralement rien pour interdire les doublons dans le /etc/passwdfichier. Le but de ce fichier est d'associer un UID à un nom physique pouvant être affiché à l'aide d'outils de ligne de commande, par exemple lslorsque l'utilisateur répertorie les fichiers.

$ 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

L’autre objectif de ce fichier est de spécifier le shell que l’utilisateur obtiendra lorsqu’il se connectera.

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

Un vecteur d’attaque courant sur les systèmes de type Unix consiste à ajouter des lignes telles que celles-ci dans un /etc/passwdfichier système :

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

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

Le rôle du /etc/passwdfichier N'EST PAS destiné à suivre uniquement les comptes d'utilisateurs. Le rôle de suivi des noms d'utilisateur et des mots de passe est la responsabilité du /etc/shadowfichier. Les fichiers tels que /etc/passwdet /etc/groupsont vraiment destinés à fournir un nom lisible par l'homme lorsque votre système répertorie les fichiers à partir de disques.

N'oubliez pas que vos fichiers sont écrits sur le disque en utilisant des noms autres que UID / GID.

$ 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: -

Notez Uid:que Gid:les chiffres sont ce qui est écrit sur le disque!

Sous Linux, tous les utilisateurs et groupes ne sont en réalité que des chiffres. C'est ce idque montre le résultat de la commande que vous avez publiée.

Le /etc/passwdfichier mappe les noms d'utilisateur sur les ID utilisateur (numéros) et, dans l'exemple que vous avez fourni, vous avez simplement mappé deux noms d'utilisateur sur le même ID utilisateur.

En effet, vous avez créé un utilisateur, test12ID 1005, qui possède également un deuxième nom d'utilisateur test13. Cependant, le système mappera l'UID 1005 sur le premier nom d'utilisateur trouvé, ce qui seraittest12

Linux "vous permet" de le faire car aucun système ne vous en empêche. /etc/passwdest simplement un fichier texte, les noms d'utilisateurs sont mappés sur l'UID trouvé pour leur entrée dans ce fichier, les UID sont mappés sur le premier nom d'utilisateur trouvé dans ce fichier.

Mais ce que vous avez créé est une situation confuse pour les autres administrateurs de systams; l'évitez en changeant l'UID detest13

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.

Le /etc/passwdfichier ne fait que mapper les noms d'utilisateur symboliques sur le véritable ID utilisateur. Si vous faites délibérément deux noms symboliques qui correspondent à un ID utilisateur, il vous le laissera.

Cela ne signifie pas que ce soit une bonne idée de le faire. Certaines personnes ont pu trouver des cas d'utilisation très spécifiques pouvant tirer parti de cette fonctionnalité, mais en général, vous ne devriez pas le faire.

Linux (et d'autres UNIX) considèrent que l'administrateur sait ce qu'il fait. Si vous lui dites de faire quelque chose de stupide, alors c'est de votre faute, à peu près de la même manière que si vous dites à votre voiture de rouler sur une falaise, vous ne pouvez pas aller voir les fabricants et demander pourquoi la voiture vous a permis de le faire.

Il existe des identifiants que le système d’exploitation attend d’être uniques, mais ils sont utilisés pour le suivi du matériel. Savoir qu'un IDentifier Universellement Unique particulier correspond à un disque dur contenant des fichiers système peut aider celui-ci à continuer de fonctionner si la configuration matérielle change. Microsoft appelle ces identifiants globaux uniques et les utilise pour suivre tous les logiciels Windows. Ironiquement, ces acronymes étaient mal choisis.

Du point de vue du système d'exploitation, la plupart des changements d'identifiant d'utilisateur et de groupe reviennent à changer d'interface externe. Il pourrait fonctionner normalement malgré les collisions. ce qui est principalement demandé aux utilisateurs et aux groupes du système, c’est qu’ils existent. Il ne peut pas savoir ce dont les utilisateurs ont besoin. Dans de telles situations, la philosophie Unix est que le système d'exploitation suppose que les administrateurs savent ce qu'ils font et les aident à le faire rapidement.

J'ai trouvé des preuves qui appuient la réponse de @ andybalholm.

À partir de APUE , § 8.15:

Tout processus peut trouver son identifiant utilisateur réel et effectif et son identifiant de groupe. Parfois, cependant, nous souhaitons connaître le nom de connexion de l'utilisateur qui exécute le programme. Nous pourrions appeler getpwuid( getuid()), mais que se passe-t-il si un seul utilisateur a plusieurs noms de connexion, chacun avec le même ID utilisateur? ( Une personne peut avoir plusieurs entrées dans le fichier de mots de passe avec le même ID utilisateur pour avoir un shell de connexion différent pour chaque entrée .) Le système garde normalement une trace du nom sous lequel nous nous sommes connectés (Section 6.8), et la getloginfonction fournit un moyen pour récupérer ce nom de connexion.

....

Étant donné le nom de connexion, nous pouvons ensuite l'utiliser pour rechercher l'utilisateur dans le fichier de mots de passe - pour déterminer le shell de connexion, par exemple - à l'aide de getpwnam.

Btw, je voudrais savoir si on peut passer à un autre shell tout en étant connecté.