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

32

Ma compréhension des UID est qu’il s’agit d’un entier positif unique attribué par un système d’exploitation de type Unix à chaque utilisateur. Chaque utilisateur est identifié au système par son UID et les noms d'utilisateur sont généralement utilisés uniquement 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?

[email protected]:~# id test12
uid=1005(test10) gid=1000(server) groups=1005(test10)
[email protected]:~# id test13
uid=1005(test10) gid=1000(server) groups=1005(test10)
[email protected]:~#

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

La sortie de /etc/passwd :

[email protected]:~$ cat /etc/passwd | grep test12
test12:x:1005:1000::/home/test12:/bin/sh
[email protected]:~$ 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 suis désorienté de savoir quel est le but de ceci, et est-ce que cela peut affecter les permissions et les journaux d'utilisateurs, etc.     

posée nux 27.02.2014 - 16:36
la source

9 réponses

35

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

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

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

    
réponse donnée Digital Chris 27.02.2014 - 16:47
la source
33

Il y a des raisons valables à cela. Par exemple, j'avais l'habitude de travailler dans un laboratoire où nous avions chacun notre propre ordinateur, mais notre $HOME se trouvait dans un lecteur partagé exporté par un serveur. Donc, mon $HOME était

/users/terdon

Comme le dossier /users n'était en fait pas sur mon ordinateur local mais exporté sur NFS, pour toute analyse lourde en E / S, j'utiliserais les données stockées sur mes disques durs locaux pour ne pas surcharger le réseau du laboratoire . À cette fin, moi-même et tous les autres utilisateurs, nous avions deux utilisateurs: l’un à l’échelle du système et l’autre au niveau de la machine en question. Le domicile de l'utilisateur local était

/home/localuser

Cependant, je devais avoir un accès complet à mes fichiers si j'étais connecté en tant que terdon ou localuser et comme notre administrateur système l'avait implémenté en donnant à la fois localuser et terdon le même UID . De cette façon, je pouvais manipuler librement mes fichiers locaux, quel que soit l'utilisateur avec lequel j'étais connecté.

    
réponse donnée terdon 27.02.2014 - 23:56
la source
12

Deux utilisateurs peuvent avoir le même UID, car il s’agit simplement d’un numéro dans un fichier texte, ce qui vous permet de définir ce que vous voulez, y compris une valeur déjà utilisée. Comme vous l’avez vu, ce n’est pas une bonne idée.

    
réponse donnée psusi 27.02.2014 - 16:45
la source
11

Unix systems & amp; Linux ne fait 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 ls lorsque les utilisateurs listent 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 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 d’un 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 fichier /etc/passwd est NOT destiné à suivre uniquement les comptes utilisateur. Le rôle du suivi du nom d'utilisateur et des mots de passe est la responsabilité du fichier /etc/shadow . Les 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 des disques.

N'oubliez pas que vos fichiers sont écrits sur le disque en utilisant les identifiants UID / GID et non les noms réels.

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

    
réponse donnée slm 27.02.2014 - 23:25
la source
10

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

    
réponse donnée andybalholm 28.02.2014 - 00:48
la source
9

Sous Linux, tous les utilisateurs et groupes ne sont en réalité que des nombres. C'est ce que la sortie de la commande id que vous avez affichée montre.

Le fichier /etc/passwd mappe les noms d’utilisateur aux utilisateurs ID (numéros) et dans l'exemple que vous avez fourni, vous avez simplement mappé deux noms d'utilisateurs au même utilisateur ID.

En effet, vous avez créé un utilisateur, test12 , ID 1005, qui a é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 "laisse" cela parce qu’il n’ya pas de système pour vous empêcher de le faire. /etc/passwd est juste un fichier texte, les noms d'utilisateur sont mappés à l'UID trouvé pour leur entrée dans ce fichier, les UID sont mappés au premier nom d'utilisateur trouvé dans ce fichier.

Mais ce que vous avez créé est une situation déroutante pour d’autres administrateurs systams; évitez-le en changeant l'UID de test13

    
réponse donnée Josh 27.02.2014 - 17:48
la source
5

La raison pour laquelle cela est autorisé aujourd'hui, c'est simplement parce que le système ne l'empêche pas.

Si cela a changé, alors cela casserait les systèmes où les administrateurs ont eu une utilisation de cette fonctionnalité (voir l'exemple de Terdon). Donc, ça n'a jamais été changé, et je ne pense pas que ce sera le cas.

À l’origine, seuls les fichiers passwd et group étaient utilisés. il n'y avait pas de commande adduser , pas de addgroup , les fichiers étaient édités par root en utilisant vi ou ed.

Il y a eu quelques bizarreries!

Afin de se souvenir du prochain identifiant utilisateur à utiliser, il était fréquent 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 l'ID utilisateur suivant. Crude, je l'avoue, mais ça a marché! Alors, pourquoi se démoniser pour le rendre plus compliqué, semblable à un développement agile aujourd'hui?

Il y avait des défauts connus. L’essentiel étant qu’il soit lisible par tous, de sorte que des utilitaires comme ls puissent 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 adduser addgroup , souvent ignorés, car ils étaient incohérents entre les Unix, de sorte que la plupart des gens ne faisaient que modifier manuellement.

Il a fallu plusieurs années avant d’inventer le fichier shadow password, ce qui apportait un peu plus de sécurité en masquant les mots de passe chiffrés. Encore une fois, juste assez de complexité a été ajouté, mais il était encore assez grossier et simple. Les utilitaires useradd et groupadd ont été introduits, ce qui a maintenu shadow et shadow- mis à jour. Pour commencer, il s’agissait souvent de simples enveloppes de script shell autour des utilitaires propriétaires adduser / addgroup propriétaires des fournisseurs. Encore une fois, c'était juste suffisant pour continuer.

Les réseaux d’ordinateurs grandissaient, les gens travaillaient sur plusieurs pour obtenir des travaux, donc l’administration des fichiers passwd/group devenait un cauchemar, en particulier avec NFS. alléger le fardeau.

Il devenait évident que quelque chose de plus flexible était nécessaire, et PAM était inventé. Donc, si vous étiez vraiment sophistiqué et que vous vouliez un système d’authentification centralisé, sécurisé, unique et unique, vous appeleriez un serveur central pour vous authentifier, peut-être un serveur Radius, un serveur LDAP ou Active Directory.

Le monde a grandi. Mais les fichiers passwd / group / shadow restaient toujours pour nous, petits utilisateurs / développeurs / laboratoires. Nous n'avions toujours pas vraiment besoin de toutes les cloches et de tous les sifflets. Je suppose que la philosophie a changé un peu maintenant, "Si vous vouliez améliorer les choses, vous ne l'utiliseriez pas du tout" , alors ne vous inquiétez pas.

C'est pourquoi je ne pense pas que le simple fichier passwd changera jamais. Cela ne sert à rien, et c'est tout simplement génial pour les Raspberry Pi de 30 £ avec 2 ou 3 températures de surveillance, et les 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 le passionné d’encapsuler useradd dans un script qui sélectionne d’abord le prochain identifiant unique dans un script. base de données (fichier) pour définir un identifiant unique, si c'est ce que vous voulez. C'est open source après tout.

    
réponse donnée X Tian 28.02.2014 - 03:34
la source
1

Le fichier /etc/passwd mappe simplement les noms d'utilisateur symboliques avec l'ID utilisateur réel. Si vous faites délibérément deux noms symboliques correspondant à un identifiant, cela vous permettra de le faire.

Cela ne signifie pas que ce soit une bonne idée de le faire. Certaines personnes ont peut-être trouvé des cas d'utilisation très spécifiques pour profiter de cette fonctionnalité, mais en général, vous ne devriez pas le faire.

Linux (et d’autres UNIX) estiment que l’administrateur sait ce qu’ils font. Si vous lui dites de faire quelque chose de stupide, 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 vous demander pourquoi. / p>     

réponse donnée user253158 28.02.2014 - 04:33
la source
1

Il existe des identificateurs que le système d'exploitation s'attend à être uniques, mais ils sont utilisés pour le suivi du matériel. Le fait de savoir qu’un identifiant unique universel correspond à un disque dur contenant des fichiers système peut aider à continuer à fonctionner si la configuration matérielle changements. Microsoft appelle ces identificateurs 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 modifications d’identificateur d’utilisateur et de groupe reviennent à modifier son interface externe. Il pourrait fonctionner normalement malgré les collisions; Ce qui est principalement requis des utilisateurs et des groupes du système, c'est qu'ils existent. Il ne peut pas savoir ce que les utilisateurs exigent. Dans de telles situations, la philosophie d’Unix est que le système d’exploitation doit assumer que les administrateurs savent ce qu’ils font et les aider à le faire rapidement.

    
réponse donnée user130144 28.02.2014 - 08:59
la source

Lire d'autres questions sur les étiquettes