Comptes NIX multiples * avec UID identique

Je suis curieux de savoir s'il existe un comportement standard attendu et s'il est considéré comme une mauvaise pratique lors de la création de plusieurs comptes sur Linux / Unix qui ont le même UID. J'ai fait quelques tests sur RHEL5 avec cela et il s'est comporté comme je m'y attendais, mais je ne sais pas si je tente le destin en utilisant cette astuce.

Par exemple, disons que j'ai deux comptes avec les mêmes identifiants:

a1:$1$4zIl1:5000:5000::/home/a1:/bin/bash
a2:$1$bmh92:5000:5000::/home/a2:/bin/bash

Cela signifie:

• Je peux me connecter à chaque compte en utilisant son propre mot de passe.
• Les fichiers que je crée auront le même UID.
• Des outils tels que "ls -l" répertorieront l'UID comme première entrée dans le fichier (a1 dans ce cas).
• J'évite les autorisations ou les problèmes de propriété entre les deux comptes car ils sont vraiment le même utilisateur.
• J'obtiens un audit de connexion pour chaque compte, j'ai donc une meilleure granularité dans le suivi de ce qui se passe sur le système.

Mes questions sont donc:

• Est-ce que cette capacité est conçue ou est-ce simplement la façon dont elle se produit?
• Est-ce que cela va être cohérent entre les variantes * nix?
• Est-ce une pratique acceptée?
• Y a-t-il des conséquences inattendues à cette pratique?

Remarque, l'idée ici est de l'utiliser pour les comptes système et non pour les comptes d'utilisateurs normaux.

Mon avis:

Est-ce que cette capacité est conçue ou est-ce simplement la façon dont elle se produit?

Il est conçu. Depuis que j'ai commencé à utiliser * NIX, vous avez pu placer les utilisateurs sur des groupes communs. La possibilité d'avoir l'UID identique sans problème n'est qu'un résultat escompté qui, comme tout, pourrait poser des problèmes s'il est mal géré.

Est-ce que cela va être cohérent entre les variantes * nix?

Je le crois.

Est-ce une pratique acceptée?

Accepté comme généralement utilisé d'une manière ou d'une autre, oui.

Y a-t-il des conséquences inattendues à cette pratique?

À part l'audit de connexion, vous n'avez rien d'autre. À moins que vous ne vouliez exactement cela, pour commencer.

Cela fonctionnera-t-il sur tous les Unix? Oui.

Est-ce une bonne technique à utiliser? Non. Il existe d'autres techniques qui sont meilleures. Par exemple, une bonne utilisation des groupes Unix et des configurations "sudo" strictement contrôlées peuvent réaliser les mêmes choses.

J'ai vu exactement un endroit où cela a été utilisé sans problème. Dans FreeBSD, il est traditionnel de créer un deuxième compte root appelé "toor" (root orthographié à l'envers) qui a / bin / sh comme shell par défaut. De cette façon, si le shell de root est gâché, vous pouvez toujours vous connecter.

Je ne peux pas fournir de réponse canonique à vos questions, mais de façon anecdotique, ma société fait cela depuis des années avec l'utilisateur root et n'a jamais eu de problème avec elle. Nous créons un utilisateur 'kroot' (UID 0) dont la seule raison d'exister est d'avoir / bin / ksh comme shell au lieu de / bin / sh ou bin / bash. Je sais que nos DBA Oracle font quelque chose de similaire avec leurs utilisateurs, ayant 3 ou 4 noms d'utilisateur par installation, tous avec les mêmes ID utilisateur (je crois que cela a été fait pour avoir des répertoires personnels séparés avec chaque utilisateur. Nous le faisons depuis au moins dix ans, sous Solaris et Linux, je pense que ça marche comme prévu.

Je ne ferais pas cela avec un compte utilisateur normal. Comme vous l'avez noté, après la connexion initiale, tout revient au prénom dans le fichier journal, donc je pense que les actions d'un utilisateur pourraient être masquées comme les actions d'un autre dans les journaux. Pour les comptes système, cela fonctionne très bien.

Est-ce que cette capacité est conçue ou est-ce simplement la façon dont elle se produit?

Conçu de cette façon.

Est-ce que cela va être cohérent entre les variantes * nix?

Ça devrait, oui.

Est-ce une pratique acceptée?

Cela dépend de ce que vous voulez dire. Ce type de chose répond à un problème extrêmement spécifique (voir comptes root / toor). Partout ailleurs et vous demandez un problème stupide à l'avenir. Si vous n'êtes pas sûr que ce soit la bonne solution, ce n'est probablement pas le cas.

Y a-t-il des conséquences inattendues à cette pratique?

Il est d'usage de traiter les noms d'utilisateur et les UID comme interchangeables. Comme l'ont souligné quelques autres personnes, les audits de connexion / activité seront inexacts. Vous voudrez également revoir le comportement de tout script / programme pertinent lié à l'utilisateur (useradd, usermod, scripts userdel de votre distribution, tout script de maintenance périodique, etc.).

Qu'essayez-vous d'accomplir avec cela qui ne serait pas accompli en ajoutant ces deux utilisateurs à un nouveau groupe et en accordant à ce groupe les autorisations dont vous avez besoin?

Y a-t-il des conséquences inattendues à cette pratique?

Il y a un problème que je connais. Cron ne joue pas bien avec cet aliasing UID. Essayez d'exécuter "crontab -i" à partir d'un script Python pour mettre à jour les entrées cron. Exécutez ensuite "crontab -e" dans le shell pour le modifier.

Notez que maintenant cron (vixie, je pense) aura mis à jour les mêmes entrées pour a1 et a2 (dans / var / spool / cron / a1 et / var / spool / cron / a2).

C'est un comportement attendu sur toutes les distributions que j'ai vues, et c'est une astuce courante que «l'ennemi» utilise pour cacher les comptes avec un accès root.

Ce n'est certainement pas standard (je n'ai vu cela en jeu nulle part), mais il ne devrait y avoir aucune raison pour que vous ne puissiez pas l'utiliser dans votre propre environnement si vous le souhaitez.

Le seul problème qui me vient à l'esprit en ce moment est que cela pourrait rendre l'audit difficile. Si vous avez deux utilisateurs avec le même uid / gid, je pense que vous aurez du mal à déterminer lequel a fait quoi lorsque vous analysez les journaux.

Le partage des ID de groupe principal est courant, donc la question tourne vraiment autour de l' UID .

J'ai déjà fait cela pour donner un accès root à quelqu'un, sans avoir à divulguer le mot de passe root - ce qui a bien fonctionné. (même si sudo aurait été un meilleur choix, je pense)

La chose principale dont je serais prudent est des choses comme la suppression de l'un des utilisateurs - le programme peut devenir confus et supprimer les deux utilisateurs, ou les fichiers appartenant aux deux, ou des choses similaires.

En fait, je pense que les programmeurs supposent probablement une relation 1: 1 entre l'utilisateur et l'UID, donc il pourrait très bien y avoir des conséquences inattendues avec d'autres programmes similaires à ce que j'ai décrit pour userdel.

BTW - cette question / réponse mise à jour pour les systèmes d'exploitation d'aujourd'hui.

Citant de redhat: la gestion des attributions uniques de numéros UID et GID , il décrit l'utilisation des UID et GID et leur gestion et comment les générateurs (serveurs d'ID)

doit générer des valeurs UID et GID aléatoires et garantir simultanément que les réplicas ne génèrent jamais la même valeur UID ou GID. La nécessité de numéros UID et GID uniques peut même traverser des domaines IdM, si une seule organisation a plusieurs domaines disparates.

De même, les utilitaires qui permettent d'accéder au système peuvent se comporter de manière imprévisible (même référence):

Si deux entrées reçoivent le même numéro d'identification, seule la première entrée est renvoyée dans la recherche de ce numéro.

Le problème survient lorsque le concept de «premier» est mal défini. Selon le service installé, les noms d'utilisateur peuvent être conservés dans un hachage de taille variable qui retournerait un nom d'utilisateur différent en fonction de facteurs incohérents. (Je sais que c'est vrai, car j'ai parfois essayé d'utiliser 2 noms d'utilisateur avec un ID, l'un étant un nom d'utilisateur local et l'autre étant un nom d'utilisateur de domaine que je voulais mapper à l'UID (que j'ai finalement abordé dans d'une manière complètement différente), mais je pouvais me connecter avec "usera", faire un "qui" ou "id" et voir "userb" OU "usera" - au hasard.

Il existe une interface pour récupérer plusieurs valeurs d'UID à partir d'un groupe (les groupes avec un seul GID sont conçus pour être associés à plusieurs UID), mais il n'y a pas d'interface portable pour renvoyer une liste de noms pour un UID, donc toute personne s'attendant à la même chose ou un comportement similaire entre des systèmes ou même des applications sur le même système peut être malheureusement surpris.

Dans Sun (maintenant oracle) yp (pages jaunes) ou NIS (NetworkInformationServices), il existe également de nombreuses références aux exigences d'unicité. Des fonctions et serveurs spéciaux sont configurés pour allouer des ID uniques sur plusieurs serveurs et domaines (par exemple, la page de manuel uid_allocd, gid_allocd - UID et GID allocator daemons

Une troisième source que l'on pourrait vérifier est la documentation du serveur de Microsoft pour le mappage de compte NFS. NFS est un protocole de partage de fichiers Unix et ils décrivent comment les autorisations et l'accès aux fichiers sont gérés par l'ID. Là, ils écrivent:

• UID. Il s'agit d'un entier non signé utilisé par les systèmes d'exploitation UNIX pour identifier les utilisateurs et doit être unique dans le fichier passwd.

• GID. Il s'agit d'un entier non signé utilisé par le noyau UNIX pour identifier les groupes et doit être unique dans le fichier de groupe. Page de gestion MS-NFS

Alors que certains systèmes d'exploitation peuvent avoir autorisé plusieurs noms / UID (dérivés BSD, peut-être?), La plupart des systèmes d'exploitation dépendent de leur caractère unique et peuvent se comporter de manière imprévisible lorsqu'ils ne le sont pas.

Remarque - J'ajoute cette page, car quelqu'un a qualifié cette entrée datée de prise en charge d'utilitaires modernes pour accueillir des UID / GID non uniques ... ce que la plupart d'entre eux ne font pas.

Je ne sais pas non plus si c'est une bonne idée ou non, mais j'utilise le comportement ci-dessus à quelques endroits. Généralement, c'est pour les comptes qui sont utilisés pour accéder au serveur ftp / sftp et mettre à jour le contenu du site Web. Cela ne semblait rien casser et semblait faciliter la gestion des autorisations alors cela aurait été avec plusieurs comptes.

Je viens de rencontrer un problème (plutôt obscur) résultant de l'utilisation de plusieurs comptes avec le même UID, et j'ai pensé le partager comme un exemple de pourquoi ce n'est pas une bonne pratique.

Dans mon cas, un fournisseur a configuré un serveur de base de données Informix et un serveur d'applications Web sur RHEL 7. Pendant la configuration, plusieurs comptes "root" avec UID 0 ont été créés (ne me demandez pas pourquoi). C'est-à-dire, "root", "user1" et "user2", tous ayant UID 0.

Le serveur RHEL 7 a ensuite été joint à un domaine Active Directory à l'aide de winbind. À ce stade, le serveur DB Informix ne pouvait plus démarrer. L'exécution oninitéchouait avec un message d'erreur indiquant celui-là "Must be a DBSA to run this program".

Voici ce que nous avons trouvé lors du dépannage:

1. L'exécution de id rootou getent passwd 0(pour résoudre l'UID 0 en nom d'utilisateur) sur un système joint à Active Directory renverrait au hasard "user1" ou "user2" au lieu de "root".

2. Informix s'appuyait apparemment sur une comparaison de chaînes pour vérifier si le nom d'utilisateur textuel de l'utilisateur qui le démarrait était "root" et échouerait autrement.

3. Sans winbind, id rootet getent passwd 0retournerait systématiquement "root" comme nom d'utilisateur.

Le correctif consistait à désactiver la mise en cache et la persistance dans /etc/nscd.conf:

enable-cache    passwd      no
persistent      passwd      no

Après cette modification, l'UID 0 s'est de nouveau résolue de manière cohérente en "root" et Informix a pu démarrer.

J'espère que cela sera utile à quelqu'un.