Quel est l'avantage de synchroniser UID / GID sur des machines Linux?

Avant de plonger dans les profondeurs de la façon de synchroniser les UID / GID sur mes différentes machines Linux, je voudrais savoir quel est réellement l'avantage?

Je sais que cela rend la synchronisation des fichiers relativement facile (car la propriété est "naturellement" conservée). Cependant, cela peut également être réalisé autrement en fonction du service de transmission.

Y a-t-il autre chose qui bénéficierait d'UID / GID cohérents?

linux synchronization uid

— alex
source

N'oubliez pas, lorsque vous modifiez uid / gid, de mettre à jour les archives (fichiers tar, etc.), ainsi que les fichiers conf qui peuvent utiliser des identifiants numériques au lieu de uidname / groupnames.

— Olivier Dulac

dette technique

Pour les raisons ci-dessous, il est beaucoup plus simple d'aborder ce problème au début pour éviter l'accumulation de dette technique . Même si vous vous trouvez déjà dans cette situation, il vaut probablement mieux y faire face dans un avenir proche que de continuer à construire.

systèmes de fichiers en réseau

Cette question semble se concentrer sur l'étendue étroite du transfert de fichiers entre des machines avec des systèmes de fichiers locaux, ce qui permet des états de propriété spécifiques à la machine.

Les considérations relatives au système de fichiers en réseau sont facilement le plus grand cas pour essayer de garder vos mappages UID / GID synchronisés, car vous pouvez généralement jeter ce "obtenu autrement" que vous avez mentionné par la fenêtre au moment où ils entrent dans l'image. Bien sûr, vous n'avez peut-être pas de systèmes de fichiers en réseau partagés entre ces hôtes en ce moment ... mais qu'en est-il de l'avenir? Pouvez-vous honnêtement dire qu'il n'y aura jamais de cas d'utilisation pour un système de fichiers en réseau introduit entre vos hôtes actuels ou des hôtes qui seront créés à l'avenir? Il n'est pas très clairvoyant de penser le contraire.

Supposons qu'il /homes'agit d'un système de fichiers en réseau partagé entre host1et host2dans les exemples suivants.

Autorisations en désaccord : /home/user1appartient à un utilisateur différent sur chaque système. Cela empêche un utilisateur d'être en mesure d'accéder de manière cohérente ou de modifier son répertoire personnel sur tous les systèmes.
chown wars : Il est très courant pour un utilisateur de soumettre un ticket demandant que les autorisations de son répertoire personnel soient fixées sur un système spécifique. La résolution de ce problème le host2casse les autorisations sur host1. Il peut parfois falloir plusieurs de ces tickets pour être travaillé avant que quelqu'un ne recule et se rende compte qu'un remorqueur de guerre est en jeu. La seule solution consiste à corriger les mappages d'ID en désaccord. Qui conduit à...
Rééquilibrage de l'enfer UID / GID : La complexité de la correction des ID augmente de façon exponentielle par le nombre de remappages impliqués pour corriger un seul utilisateur sur plusieurs machines. ( user1a l'ID de user2, mais user2a l'ID de user17... et ce n'est que le premier système du cluster) Plus vous attendez pour résoudre le problème, plus ces chaînes peuvent devenir complexes, nécessitant souvent le temps d'indisponibilité des applications sur plusieurs serveurs afin de synchroniser les choses correctement.
Problèmes de sécurité : user2on host2a le même UID que user1on host1, ce qui leur permet d'écrire /home/user1sur host2sans le savoir user1. Ces modifications sont ensuite évaluées host1avec les autorisations de user1. Qu'est ce qui pourrait aller mal? (si user1est un utilisateur de l' application, quelqu'un dev va découvrir qu'il est inscriptible et va faire des changements. c'est un temps fait ses preuves.)

Il existe d'autres scénarios, et ce ne sont que des exemples des plus courants.

les noms ne sont pas toujours une option

Tous les scripts ou fichiers de configuration écrits avec des ID numériques deviennent intrinsèquement non transférables dans votre environnement. Généralement, ce n'est pas un problème car la plupart des gens ne codent pas en dur à moins qu'ils ne soient absolument tenus de le faire ... mais parfois l'outil avec lequel vous travaillez ne vous donne pas le choix. Dans ces scénarios, vous êtes obligé de gérer n versions différentes du script ou du fichier de configuration.

Exemple: pam_succeed_ifvous permet d'utiliser les champs de user, uidet gid... une option « groupe » brille par son absence. Si vous étiez placé dans une position où plusieurs systèmes étaient censés implémenter une certaine forme de restriction d'accès basée sur le groupe, vous auriez n différentes variantes des configurations PAM. (ou au moins un seul GID sur lequel vous devez éviter les collisions)

gestion centralisée

la réponse de natxo a assez bien couvert cela.

— Andrew B
source

Je ne suis pas sûr qu'il soit correct de dire que l'utilisation d'un système de fichiers en réseau empêche de résoudre les problèmes avec différents uids, je connais au moins un système de fichiers qui prend en charge une carte uid vous permettant de spécifier quels groupes et utilisateurs correspondent sur différentes machines.

— Vality

@Vality S'il s'agissait d'une solution couramment disponible, j'hésiterais encore à l'appeler évolutive.

— Andrew B

Je suis d'accord, je ne voulais tout simplement pas faire croire au PO que c'est impossible, je suis largement d'accord avec votre suggestion selon laquelle la meilleure solution est de les garder synchronisés.

— Vality

Merci! Malheureusement, "tôt" est révolu depuis longtemps. Bien que je sache qu'une configuration ldap / kerberos est quelque chose que j'aimerais inclure ici où je travaille, mais ce ne serait pas maintenant. Pour d'autres raisons, j'étais particulièrement intéressé par l'utilisation de l'UID / GID sur les systèmes interopérables. Comme je l'ai dit, le transfert de fichiers est un problème (qui a actuellement le statut "ça marche"), c'est pourquoi je voulais savoir s'il y avait d'autres choses (comme vous l'avez mentionné) également affectées par les UID. Pourriez-vous ajouter des mots clés de ces "autres scénarios"? Cela ferait de cela une réponse splendide!

— alex

@alex Eh bien, je voulais dire "d'autres scénarios" en termes de problèmes de système de fichiers en réseau. Peu importe la fin du jeu, le problème ne fait que s'aggraver car il n'est pas résolu. Si les raisons que nous avons fournies ne sont pas adéquates, il serait probablement utile que vous orientiez un peu plus votre question en fournissant ces "autres raisons". Les réponses fournies jusqu'à présent sont plutôt bonnes à mon avis. Si vous essayez de persuader la direction, il ne nous incombe pas de lui faire faire la bonne chose.

— Andrew B

une fois que vous atteignez une certaine taille (et c'est toujours plus tôt que vous ne le pensez), vous vous rendrez compte que changer vos mots de passe ou désactiver des comptes pour quelqu'un sur tous les hôtes est un PITA. C'est pourquoi les gens utilisent des systèmes avec des bases de données LDAP (ou NIS mais ne le font pas, pas sûr de nos jours) comme openldap ou de nos jours l'excellent freeipa.

Vous conservez toutes les informations des comptes / groupes dans une base de données centrale, tous les hôtes partagent ces informations. Vous pouvez faire beaucoup plus de choses à partir de là: utiliser les informations des utilisateurs pour les autorisations de fichiers, bien sûr, mais aussi créer des utilisateurs virtuels pour toutes les applications qui ont des liaisons LDAP au lieu d'avoir à y créer vos utilisateurs également (de nombreuses applications Web peuvent utiliser ldap pour leur base de données utilisateurs), maintenir une base de données centrale sudo rules, distribuer votre environnement autofs, conserver vos zones DNS, ...

— natxo asenjo
source