Múltiplas contas * NIX com UID idêntico

Question

Estou curioso para saber se existe um comportamento esperado padrão e se é considerado uma prática ruim ao criar mais de uma conta no Linux / Unix que tenha o mesmo UID. Eu fiz alguns testes no RHEL5 com isso e ele se comportou como eu esperava, mas não sei se estou tentando o destino usando esse truque.

Como exemplo, digamos que eu tenha duas contas com os mesmos IDs:

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

O que isto significa é:

• Eu posso fazer login em cada conta usando sua própria senha.
• Os arquivos que eu criar terão o mesmo UID.
• Ferramentas como "ls -l" listarão o UID como a primeira entrada no arquivo (a1 neste caso).
• Evito quaisquer permissões ou problemas de propriedade entre as duas contas, porque elas são realmente o mesmo usuário.
• Recebo uma auditoria de login para cada conta, por isso tenho maior granularidade para acompanhar o que está acontecendo no sistema.

Então, minhas perguntas são:

• Essa habilidade é projetada ou é apenas a maneira como ela funciona?
• Isso será consistente em todas as variantes * nix?
• Essa prática é aceita?
• Existem conseqüências não intencionais para essa prática?

Note que a ideia aqui é usar isso para contas do sistema e não para contas de usuários normais.

    

Answer 1

Minha opinião:

Essa habilidade é projetada ou é apenas a maneira como ela funciona?

Ele é projetado. Desde que comecei a usar o * NIX, você conseguiu colocar usuários em grupos comuns. A capacidade de fazer com que o UID seja o mesmo sem problemas é apenas um resultado pretendido que, como tudo, pode trazer problemas se for gerenciado incorretamente.

Isso será consistente em todas as variantes * nix?

Eu acredito que sim.

Esta prática é aceita?

Aceito como geralmente usado de uma forma ou de outra, sim.

Existem consequências não intencionais para essa prática?

Além da auditoria de login, você não tem mais nada. A menos que você quisesse exatamente isso, para começar.

    

Answer 2

Funcionará em todos os Unixes? Sim.

É uma boa técnica para usar? Não. Existem outras técnicas que são melhores. Por exemplo, o uso adequado de grupos unix e configurações "sudo" estritamente controladas podem alcançar as mesmas coisas.

Eu vi exatamente um lugar onde isso foi usado sem problemas. No FreeBSD é tradicional criar uma segunda conta root chamada "toor" (raiz soletrada para trás) que tem / bin / sh como o shell padrão. Dessa forma, se o shell do root ficar bagunçado, você ainda poderá efetuar login.

    

Answer 3

Essa habilidade é projetada ou é apenas a maneira como ela funciona?

Projetado dessa maneira.

Isso será consistente em todas as variantes * nix?

Deveria sim.

Esta prática é aceita?

Depende do que você quer dizer. Esse tipo de coisa responde a um problema extremamente específico (veja root / toor accounts). Em qualquer outro lugar e você está pedindo um problema estúpido no futuro. Se você não tem certeza se esta é a solução certa, provavelmente não é.

Existem consequências não intencionais para essa prática?

É geralmente costume tratar nomes de usuário e UIDs como intercambiáveis. Como algumas outras pessoas apontaram, as auditorias de login / atividade serão imprecisas. Você também vai querer rever o comportamento de quaisquer scripts / programas relevantes relacionados ao usuário (os scripts useradd, usermod, userdel da sua distro, quaisquer scripts de manutenção periódicos, etc.).

O que você está tentando realizar com isso que não seria realizado adicionando esses dois usuários a um novo grupo e concedendo a esse grupo as permissões necessárias?

    

Answer 4

Existem consequências não intencionais para essa prática?

Há um problema que conheço. Cron não joga bem com esse alias de UID. Tente executar o "crontab -i" a partir de um script Python para atualizar as entradas do cron. Em seguida, execute "crontab -e" no shell para modificar o mesmo.

Observe que agora o cron (vixie, eu acho) atualizará as mesmas entradas para a1 e a2 (em / var / spool / cron / a1 e / var / spool / cron / a2).

    

Answer 5

Eu não posso fornecer uma resposta canônica para suas perguntas, mas, informalmente, minha empresa faz isso há anos com o usuário root e nunca teve problemas com isso. Criamos um usuário 'kroot' (UID 0) cujo único motivo de existência é ter / bin / ksh como o shell em vez de / bin / sh ou bin / bash. Eu sei que nossos DBAs Oracle fazem algo semelhante com seus usuários, tendo 3 ou 4 nomes de usuário por instalação, todos com os mesmos IDs de usuário (acredito que isso foi feito para ter diretórios pessoais separados com cada usuário. Temos feito isso pelo menos dez anos, no Solaris e no Linux, acho que está funcionando como planejado.

Eu não faria isso com uma conta de usuário comum. Como você observou, após o login inicial, tudo volta para o primeiro nome no arquivo de log, então acho que as ações de um usuário podem ser mascaradas como as ações de outro nos logs. Para contas do sistema, embora funcione bem.

    

Answer 6

Esse é o comportamento esperado em todas as distribuições que vi e é um truque comum que 'o inimigo' usa para ocultar contas com acesso root.

Certamente não é padrão (eu não vi isso em jogo em nenhum lugar), mas não deve haver qualquer razão para que você não possa usá-lo em seu próprio ambiente se achar conveniente.

A única pegadinha que vem à mente agora é que isso pode dificultar a auditoria. Se você tiver dois usuários com o mesmo uid / gid, acredito que será difícil descobrir qual deles fez o quê, quando estiver analisando logs.

    

Answer 7

O compartilhamento de IDs primários de grupos é comum, então a questão realmente gira em torno do UID .

Já fiz isso antes para dar acesso a alguém, sem precisar divulgar a senha de root - que funcionou bem. (embora o sudo tenha sido uma escolha melhor, eu acho)

A principal coisa que eu seria cauteloso sobre coisas como excluir um dos usuários - o programa pode ficar confuso e excluir os usuários, ou arquivos pertencentes a ambos, ou coisas semelhantes.

Na verdade, acho que os programadores provavelmente Assumem uma relação de 1: 1 entre usuário e UID, então pode muito bem haver consequências inesperadas com outros programas semelhantes ao que descrevi para userdel.

    

Answer 8

Eu também não sei se é uma boa ideia ou não, mas eu uso o comportamento acima em alguns lugares. Principalmente, é para contas que são usadas para acessar o servidor ftp / sftp e atualizar o conteúdo do site. Ele não pareceu quebrar nada e pareceu facilitar o manuseio de permissões, do que teria sido com várias contas.

    

Answer 9

BTW - esta pergunta / resposta foi atualizada para os sistemas operacionais atuais.

Citação de redhat: gerenciamento de atribuições exclusivas de UID e número de GID , descreve o uso de UID e GID e seu gerenciamento e como geradores (servidores de ID)

must generate random UID and GID values and simultaneously ensure that replicas never generate the same UID or GID value. The need for unique UID and GID numbers might even cross IdM domains, if a single organization has multiple disparate domains.

Da mesma forma, os utilitários que permitem acesso ao sistema podem se comportar de forma imprevisível (mesma referência):

If two entries are assigned the same ID number, only the first entry is returned in a search for that number.

O problema surge quando o conceito de "primeiro" é mal definido. Dependendo do serviço instalado, os nomes de usuário podem ser mantidos em um hash de tamanho variável que retorne um nome de usuário diferente com base em fatores inconsistentes. (Eu sei que isso é verdade, já que algumas vezes eu tentei usar 2 nomes de usuários com um ID, um sendo um nome de usuário local, e o outro sendo um domain.username que eu queria mapear para o UID uma maneira completamente diferente), mas eu poderia logar com "usera", fazer um "who" ou "id" e ver "userb" ou "usera" - aleatoriamente.

Há uma interface para recuperar vários valores de UIDs de um grupo (grupos com um único GID são projetados para serem associados a vários UIDs), mas não há uma interface portátil para retornar uma lista de nomes para um UID. Esperar o mesmo ou semelhante comportamento entre sistemas ou mesmo aplicativos no mesmo sistema pode ser infeliz surpresa.

No Sol (agora oracle) yp (páginas amarelas) ou NIS (NetworkInformationServices), há também muitas referências a requisitos de exclusividade. Funções especiais e servidores são configurados para alocar IDs exclusivas em vários servidores e domínios (por exemplo, uid_allocd, gid_allocd - manpage de daemons do alocador de UID e GID

Uma terceira fonte que se pode verificar é a documentação do servidor da Microsoft para o Mapeamento de Contas NFS. O NFS é um protocolo de compartilhamento de arquivos unix e descreve como as permissões e o acesso aos arquivos são mantidos pelo ID. Lá eles escrevem:

• UID. Este é um inteiro não assinado usado pelos sistemas operacionais UNIX para identificar usuários e deve ser exclusivo no arquivo passwd.

• GID. Este é um inteiro não assinado usado pelo kernel do UNIX para identificar grupos e deve ser exclusivo no arquivo de grupo. gerenciamento MS-NFS página

Embora alguns sistemas operacionais possam ter permitido vários nomes / UIDs (derivados do BSD, talvez?), a maioria dos sistemas operacionais depende do fato de serem únicos e podem se comportar de maneira imprevisível quando não são.

Nota - Estou adicionando esta página, como alguém se referiu a esta entrada datada como suporte para utilitários modernos para acomodar UID / GIDs não exclusivos ... que a maioria, não.

    

Answer 10

Acabei de encontrar um problema (bastante obscuro) decorrente do uso de várias contas com o mesmo UID e pensei em compartilhá-lo como um exemplo de por que isso não é uma boa prática.

No meu caso, um fornecedor configurou um servidor de banco de dados Informix e um servidor de aplicativos web no RHEL 7. Durante a configuração, várias contas "raiz" com UID 0 foram criadas (não me pergunte por quê). Ou seja, "root", "user1" e "user2", todos com UID 0.

O servidor RHEL 7 foi posteriormente associado a um domínio do Active Directory usando o winbind. Neste ponto, o servidor do Informix DB não pôde mais ser iniciado. A execução de oninit falhou com uma mensagem de erro dizendo que um "Must be a DBSA to run this program" .

Veja o que encontramos durante a solução de problemas:

1. A execução de id root ou getent passwd 0 (para resolver o UID 0 em um nome de usuário) em um sistema associado ao Active Directory retornaria aleatoriamente "user1" ou "user2" em vez de "root".

2. O Informix aparentemente dependia de uma comparação de string para verificar se o nome de usuário textual do usuário que o iniciava era "root" e falharia de outra forma.

3. Sem o winbind, id root e getent passwd 0 retornariam "root" como nome de usuário.

A correção foi desativar o armazenamento em cache e a persistência em /etc/nscd.conf :

enable-cache    passwd      no
persistent      passwd      no

Após essa mudança, o UID 0 mais uma vez consistentemente resolveu "root" e o Informix pode iniciar.

Espero que isso seja útil para alguém.