Qual é a vantagem de sincronizar o UID / GID em máquinas Linux?

Question

Antes de mergulhar nas profundezas de como sincronizar os UID's / GIDs em minhas diferentes máquinas Linux, gostaria de saber qual é realmente o benefício?

Eu sei que isso mantém a sincronização de arquivos relativamente fácil (já que a propriedade é "naturalmente" retida). No entanto, isso também pode ser obtido de outra forma, dependendo do serviço de transmissão.

Existe mais alguma coisa que se beneficiaria de UIDs / GIDs consistentes?

    

Answer 1

dívida técnica

Pelas razões abaixo, é muito mais simples resolver esse problema desde o início para evitar o acúmulo de dívida técnica . Mesmo que você já esteja nessa situação, provavelmente é melhor lidar com isso no futuro próximo do que continuar construindo.

sistemas de arquivos em rede

Essa questão parece estar focada no escopo limitado da transferência de arquivos entre máquinas com sistemas de arquivos locais, o que permite estados de propriedade específicos da máquina.

Considerações de sistema de arquivos em rede são facilmente o maior caso para tentar manter seus mapeamentos de UID / GID em sincronia, porque geralmente é possível usar a palavra "alcançado de outra forma" que você mencionou na janela no momento em que entra na imagem. Claro, você pode não ter sistemas de arquivos em rede compartilhados entre esses hosts agora ... mas e o futuro? Você pode honestamente dizer que nunca haverá um caso de uso para um sistema de arquivos em rede sendo introduzido entre seus hosts atuais ou hosts que são criados no futuro? Não é muito para a frente pensar em assumir o contrário.

Suponha que /home seja um sistema de arquivos em rede compartilhado entre host1 e host2 nos exemplos a seguir.

• Permissões discordantes : /home/user1 é de propriedade de um usuário diferente em cada sistema. Isso impede que um usuário possa acessar ou modificar consistentemente seu diretório inicial em sistemas.
• chown wars : é muito comum que um usuário envie um ticket solicitando que as permissões do diretório base sejam fixadas em um sistema específico. Corrigir este problema em host2 quebra as permissões em host1 . Às vezes pode levar vários desses ingressos para serem trabalhados antes que alguém dê um passo para trás e perceba que um cabo de guerra está em jogo. A única solução é corrigir os mapeamentos de ID discordantes. O que leva a ...
• Reequilíbrio infernal do UID / GID : A complexidade da correção de IDs aumenta exponencialmente pelo número de remapeamentos envolvidos para corrigir um único usuário em várias máquinas. ( user1 tem o ID de user2 , mas user2 tem o ID de user17 ... e esse é apenas o primeiro sistema no cluster) Quanto mais tempo você espera para corrigir o problema, mais complexas são essas cadeias pode se tornar, muitas vezes exigindo o tempo de inatividade de aplicativos em vários servidores para que as coisas fiquem sincronizadas corretamente.
• Problemas de segurança : user2 on host2 tem o mesmo UID que user1 on host1 , permitindo que gravem em /home/user1 on host2 sem o conhecimento de user1 . Essas alterações são avaliadas em host1 com as permissões de user1 . O que poderia dar errado? (se user1 for um usuário do aplicativo, alguém em dev irá descobrir que é gravável e fará alterações. este é um fato comprovado pelo tempo.)

Existem outros cenários, e estes são apenas exemplos dos mais comuns.

nomes nem sempre são uma opção

Quaisquer scripts ou arquivos de configuração gravados em relação a IDs numéricos tornam-se inerentemente não suportáveis em seu ambiente. Geralmente não é um problema porque a maioria das pessoas não o codifica a menos que seja absolutamente necessário ... mas às vezes a ferramenta com a qual você está trabalhando não lhe dá uma escolha no assunto. Nesses cenários, você é forçado a manter n versões diferentes do script ou do arquivo de configuração.

Exemplo: pam_succeed_if permite que você use campos de user , uid e gid ... uma opção "grupo" está conspicuamente ausente. Se você fosse colocado em uma posição onde era esperado que vários sistemas implementassem alguma forma de restrição de acesso baseada em grupo, você teria n variações diferentes das configurações do PAM. (ou pelo menos um único GID para evitar colisões)

gerenciamento centralizado

A resposta da natxo está bem coberta.

    

Answer 2

depois de atingir um determinado tamanho (e é sempre mais cedo do que você pensa), você perceberá que alterar suas senhas ou desativar contas de alguém em todos os hosts é uma PITA. É por isso que as pessoas usam sistemas com bancos de dados LDAP (ou NIS, mas não fazem isso, não são seguros hoje em dia) como o openldap ou hoje em dia o excelente freeipa.

Você mantém todas as informações de contas / grupos em um banco de dados central, todos os hosts compartilham essas informações. Você pode fazer muito mais coisas a partir daí: usar as informações dos usuários para permissões de arquivos, é claro, mas também criar usuários virtuais para todos os aplicativos que possuem ligações ldap em vez de criar seus usuários também (muitos aplicativos da Web podem usar ldap para seu banco de dados de usuários), mantenha um banco de dados central de regras sudo, distribua seu ambiente autofs, mantenha suas zonas dns, ...