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: test12 et 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 demande quel est le but de cette opération. Cela peut-il affecter les autorisations, les journaux des utilisateurs, etc. Si un utilisateur est ajouté avec uid=0 et gid=0 aura des privilèges similaires à un compte root?
La réponse ici est que Linux ne vous protège pas contre vous-même.
Si vous voulez vraiment su root et aller 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 $HOME était dans un lecteur partagé exporté par un serveur. Donc, mon $HOME était
/users/terdon
Étant donné que le dossier /users n'était pas réellement sur ma machine locale mais exporté via NFS, pour toute analyse qui nécessitait beaucoup d'E/S, j'utiliserais les données stockées sur mes disques durs locaux 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é en tant que terdon ou en tant que localuser et de la façon dont notre administrateur système l'avait implémenté en donnant le même UID à localuser et terdon. 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 autre shell, généralement bash.
Les systèmes Unix et Linux ne font généralement rien pour interdire les doublons dans le fichier /etc/passwd. Le but de ce fichier est d'associer un UID à un nom physique pouvant être affiché par des outils de ligne de commande, tels que lslorsque les utilisateurs répertorient des 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 quel shell un 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 au fichier /etc/passwd du 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 fichier /etc/passwd a pour rôle NOT uniquement de suivre les comptes d'utilisateurs. Le rôle de suivi du nom d'utilisateur et des mots de passe est la responsabilité du fichier /etc/shadow. Des fichiers tels que /etc/passwd et /etc/group sont 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 les Uid: et Gid:, les nombres sont ce qui est réellement écrit sur le disque!
Sous Linux, tous les utilisateurs et groupes ne sont en réalité que des chiffres. C’est ce que montre le résultat de la commande id que vous avez publiée.
Le fichier /etc/passwd mappe l'utilisateur noms à l'utilisateur ID (chiffres). 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, test12, ID 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é, à savoir test12.
Linux "vous permet" de le faire car aucun système ne vous en empêche. /etc/passwd est juste 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 de test13
La raison pour laquelle cela est autorisé aujourd'hui, c'est simplement parce que le système ne l'empêche pas.
Si cela change, les systèmes où les administrateurs ont une utilisation de cette fonctionnalité seraient cassé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 , pas de addgroup , les fichiers ont été édités par root en utilisant 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 comme dernière ligne avec un nom d'utilisateur de ! (car ! était un nom d'utilisateur invalide) et cette entrée était utilisée pour stocker le prochain identifiant. 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 doit être lisible par tout le monde, afin que des utilitaires comme lspuissent mapper 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 adduseraddgroupname__, 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 fichier de mots de passe shadowne 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, en maintenant shadowet shadow- mis à jour. Pour commencer, il s’agissait souvent de simples wrappers de scripts Shell autour des utilitaires propriétaires du fournisseur adduser/addgroup . Encore une fois, c'était juste suffisant pour continuer.
Les réseaux d'ordinateurs grandissaient, les gens travaillaient plusieurs fois à la fois pour obtenir des travaux. L'administration des fichiers passwd/group était en train de devenir un cauchemar, en particulier avec NFS. C'est ainsi que Yellow Pages, également appelé NIS, allégeait 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 vous authentifier, par exemple un serveur Radius, un serveur LDAP ou Active Directory.
Le monde avait grandi. Mais les fichiers passwd/group/shadow restaient encore pour nous les plus petits utilisateurs/développeurs/laboratoires. Nous n’avions toujours pas vraiment besoin des cloches et des sifflets. J'imagine que la philosophie avait un peu changé pour passer à "Si vous deviez améliorer la situation, vous ne l'utiliseriez pas du tout" , alors ne vous inquiétez pas pour ça.
C'est pourquoi je ne pense pas que le fichier passwd simple changera jamais. Cela ne sert plus à rien, 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 d’utilisateur si vous voulez qu’ils soient uniques, et rien n’empêche les passionnés d’envelopper useradd dans un script qui sélectionne d'abord le prochain identifiant unique dans une base de données (fichier) pour définir un identifiant unique, si c'est ce que vous voulez. Il est open source après tout.
Le fichier /etc/passwd mappe simplement 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, 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 particulier 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.
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
getpwuidname __ (getuidname __ ()), mais que se passera-t-il si un seul utilisateur possède plusieurs noms de connexion, chacun avec le même ID utilisateur? (ne personne peut avoir plusieurs entrées dans le fichier de mots de passe avec le même ID utilisateur pour avoir un shell 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 fonctiongetloginpermet d'extraire 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
getpwnamname__.
Au fait, j'aimerais savoir si on peut passer à un autre Shell en étant connecté.