Várias contas * NIX com UID idêntico

Estou curioso para saber se existe um comportamento padrão esperado e se é considerado uma prática ruim ao criar mais de uma conta no Linux / Unix que possua o mesmo UID. 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 tenho 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 isso significa é:

• 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 permissões ou problemas de propriedade entre as duas contas, porque eles são realmente o mesmo usuário.
• Eu recebo auditoria de login para cada conta, para ter uma granularidade melhor no rastreamento do que está acontecendo no sistema.

Então, minhas perguntas são:

• Essa capacidade foi projetada ou é do jeito que acontece?
• Isso será consistente nas variantes * nix?
• Esta prática é aceita?
• Existem consequências não intencionais para esta prática?

Observe que a idéia aqui é usar isso para contas do sistema e não para contas de usuário normais.

Minha opinião:

Essa capacidade foi projetada ou é do jeito que acontece?

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

Isso será consistente nas variantes * nix?

Eu acredito que sim.

Esta prática é aceita?

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

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

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

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 estritamente controladas "sudo" podem obter as mesmas coisas.

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

Não posso fornecer uma resposta canônica para suas perguntas, mas, curiosamente, minha empresa faz isso há anos com o usuário root e nunca tive problemas com isso. Criamos um usuário 'kroot' (UID 0) cuja única razão de existência é ter / bin / ksh como shell em vez de / bin / sh ou bin / bash. 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. Fazemos isso há pelo menos dez anos no Solaris e Linux, acho que está funcionando como projetado.

Eu não faria isso com uma conta de usuário comum. Como você observou, após o login inicial, tudo volta ao 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.

Essa capacidade foi projetada ou é do jeito que acontece?

Projetado dessa maneira.

Isso será consistente nas 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 (consulte contas root / toor). 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 esta prática?

É costume geral 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 deseja revisar o comportamento de quaisquer scripts / programas relacionados ao usuário relevantes (os scripts useradd, usermod, userdel da sua distribuição, quaisquer scripts de manutenção periódica, 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?

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

Estou ciente de um problema. Cron não funciona bem com esse aliasing de UID. Tente executar "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, acho) terá atualizado as mesmas entradas para a1 e a2 (em / var / spool / cron / a1 e / var / spool / cron / a2).

Esse é o comportamento esperado em todas as distribuições que eu já 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 nenhuma razão para que você não possa usá-lo em seu próprio ambiente, se desejar.

A única coisa 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 que quando está analisando logs.

Compartilhar IDs de grupo primário é comum; portanto, a questão realmente gira em torno do UID .

Eu fiz isso antes para dar a alguém acesso root, sem ter que divulgar a senha root - que funcionou bem. (embora sudo tivesse sido uma escolha melhor, eu acho)

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

Na verdade, acho que os programadores provavelmente assumem um relacionamento 1: 1 entre usuário e UID, portanto, muito bem, pode haver consequências inesperadas com outros programas semelhantes ao que descrevi para o userdel.

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

Citando from redhat: gerenciando atribuições exclusivas de UID e GID Number , ele descreve o uso de UID e GIDs e seu gerenciamento e como geradores (servidores de ID)

deve gerar valores aleatórios de UID e GID e simultaneamente garantir que as réplicas nunca gerem o mesmo valor de UID ou GID. A necessidade de números UID e GID exclusivos pode até cruzar domínios do IdM, se uma única organização tiver vários domínios diferentes.

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

Se duas entradas tiverem o mesmo número de ID atribuído, somente a primeira entrada será retornada em uma pesquisa para esse número.

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 retornaria um nome de usuário diferente com base em fatores inconsistentes. (Sei que isso é verdade, já que às vezes tentei usar 2 nomes de usuário com um ID, um sendo um nome de usuário local e o outro um domain.username que eu queria mapear para o UID (que acabei abordando em uma maneira completamente diferente), mas eu poderia fazer login com "usera", fazer um "who" ou "id" e ver "userb" OU "usera" - aleatoriamente.

Existe 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 existe uma interface portátil para retornar uma lista de nomes para um UID, portanto, qualquer pessoa que espere o mesmo ou comportamento semelhante entre sistemas ou mesmo aplicativos no mesmo sistema pode ser surpreendentemente infeliz.

No Sun (agora oracle) yp (páginas amarelas) ou NIS (NetworkInformationServices), também existem muitas referências a requisitos de exclusividade. Funções e servidores especiais são configurados para alocar IDs exclusivos em vários servidores e domínios (exemplo: uid_allocd, gid_allocd - página de manual dos daemons do alocador 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 eles descrevem como as permissões e o acesso ao arquivo são mantidos pelo ID. Lá, eles escrevem:

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

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

Enquanto alguns sistemas operacionais podem ter permitido vários nomes / UID (derivados do BSD, talvez?), A maioria dos sistemas operacionais depende disso, sendo único e pode se comportar de maneira imprevisível quando não é.

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

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

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 da web no RHEL 7. Durante a configuração, várias contas "raiz" com o UID 0 foram criadas (não me pergunte por que). 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. Nesse ponto, o servidor do Informix DB não pôde mais ser iniciado. A execução oninitestava falhando com uma mensagem de erro dizendo que um"Must be a DBSA to run this program" .

Aqui está o que encontramos durante a solução de problemas:

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

2. Aparentemente, o Informix estava confiando em uma comparação de cadeias para verificar se o nome de usuário textual do usuário que estava iniciando era "raiz" e, caso contrário, falharia.

3. Sem o winbind, id roote getent passwd 0retornaria consistentemente "root" como o nome do usuário.

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

enable-cache    passwd      no
persistent      passwd      no

Após essa alteração, o UID 0 novamente foi resolvido consistentemente como "root" e o Informix pôde iniciar.

Espero que isso seja útil para alguém.