Solution 1 :
Mon avis :
Cette capacité est-elle conçue ou est-ce simplement la façon dont elle fonctionne ?
Il est conçu. Depuis que j'ai commencé à utiliser *NIX, vous avez pu placer des utilisateurs dans des groupes communs. La possibilité d'avoir l'UID identique sans problème n'est qu'un résultat escompté qui, comme tout, peut entraîner des problèmes s'il est mal géré.
Cela va-t-il ê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.
Cette pratique a-t-elle des conséquences imprévues ?
À part l'audit de connexion, vous n'avez rien d'autre. À moins que vous ne vouliez exactement cela, pour commencer.
Solution 2 :
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 utilisation appropriée des groupes Unix et des configurations "sudo" strictement contrôlées peuvent permettre d'obtenir les mêmes résultats.
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 endommagé, vous pouvez toujours vous connecter.
Solution 3 :
Je ne peux pas fournir de réponse canonique à vos questions, mais pour l'anecdote, mon entreprise le fait depuis des années avec l'utilisateur root et n'a jamais eu de problème avec. Nous créons un utilisateur 'kroot' (UID 0) dont la seule raison d'être 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 identifiants d'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, sur Solaris et Linux. Je pense que cela fonctionne comme prévu.
Je ne ferais pas cela avec un compte d'utilisateur régulier. 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.
Solution 4 :
Cette pratique a-t-elle des conséquences imprévues ?
Il y a un problème dont je suis conscient. Cron ne fonctionne pas bien avec cet alias UID. Essayez d'exécuter "crontab -i" à partir d'un script Python pour mettre à jour les entrées cron. Ensuite, exécutez "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).
Solution 5 :
Cette capacité est-elle conçue ou est-ce simplement la façon dont elle fonctionne ?
Conçu de cette façon.
Cela va-t-il ê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 genre de chose répond à un problème extrêmement spécifique (voir comptes root/toor). N'importe où 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.
Cette pratique a-t-elle des conséquences imprévues ?
Il est de coutume générale de traiter les noms d'utilisateur et les UID comme interchangeables. Comme quelques autres personnes l'ont souligné, les audits de connexion/activité seront inexacts. Vous voudrez également examiner le comportement de tous les scripts/programmes pertinents liés à l'utilisateur (les scripts useradd, usermod, userdel de votre distribution, tous les scripts de maintenance périodique, etc.).
Qu'essayez-vous d'accomplir avec ceci qui ne serait pas accompli en ajoutant ces deux utilisateurs à un nouveau groupe et en accordant à ce groupe les autorisations dont vous avez besoin ?