it-swarm-pt.tech

Várias contas * NIX com UID idêntico

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

Por 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 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).
  • Eu evito quaisquer permissões ou problemas de propriedade entre as duas contas porque são realmente o mesmo usuário.
  • Recebo auditoria de login para cada conta, então tenho melhor granularidade para rastrear o que está acontecendo no sistema.

Então, minhas perguntas são:

  • Essa capacidade foi projetada ou é apenas a maneira como funciona?
  • Isso vai ser consistente nas variantes * nix?
  • Esta é uma prática aceita?
  • Existem consequências não intencionais para esta prática?

Observe, a ideia aqui é usar isso para contas de sistema e não contas de usuário normais.

14
Tim

Minha opinião:

Esta habilidade é projetada ou é apenas a maneira como funciona?

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

Isso vai ser consistente entre as variantes * nix?

Eu acredito que sim.

Esta é uma prática aceita?

Aceito como geralmente usado de uma forma 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ê quisesse exatamente isso, para começar.

8
user1797

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 de "Sudo" estritamente controladas podem atingir os mesmos resultados.

Eu vi exatamente um lugar onde isso foi usado sem problemas. No FreeBSD é tradicional criar uma segunda conta de root chamada "toor" (root escrito ao contrário) que tem/bin/sh como o Shell padrão. Desta forma, se o Shell do root ficar bagunçado, você ainda pode fazer o login.

7
TomOnTime

Não posso fornecer uma resposta canônica às suas perguntas, mas, curiosamente, minha empresa tem feito isso há anos com o usuário root e nunca teve problemas com isso. Criamos um usuário 'kroot' (UID 0) cuja única razão de existência é ter/bin/ksh como o 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 para cada usuário. Fazemos isso há pelo menos dez anos, em Solaris e Linux. Acho que está funcionando como planejado.

Eu não faria isso com uma conta de usuário normal. Como você notou, 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 de sistema, funciona muito bem.

4
jj33

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

Estou ciente de um problema. O 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, eu acho) terá atualizado as mesmas entradas para a1 e a2 (em/var/spool/cron/a1 e/var/spool/cron/a2).

4
Sridhar Ratnakumar

Esta habilidade é projetada ou é apenas a maneira como funciona?

Projetado dessa forma.

Isso vai ser consistente entre as variantes * nix?

Deveria, sim.

Esta é uma prática aceita?

Depende do que você quer dizer. Esse tipo de coisa responde a um problema extremamente específico (consulte contas de 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?

É um 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 vai querer revisar o comportamento de quaisquer scripts/programas relevantes relacionados ao usuário (useradd, usermod, scripts de userdel de sua distro, 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 de que você precisa?

4
sh-beta

Este é 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 nenhum lugar), mas não deve haver nenhuma razão para que você não possa usar isso em seu próprio ambiente, se achar necessário.

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 terá dificuldade em descobrir qual deles fez o quê quando estiver analisando os logs.

3
Michael Gorsuch

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

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

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

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

3
Brent

BTW - esta pergunta/resposta atualizada para os sistemas operacionais de hoje.

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

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

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

Se duas entradas forem atribuídas ao mesmo número de ID, apenas a primeira entrada será retornada em uma busca por aquele número.

O problema surge quando o conceito de "primeiro" está 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. (Eu 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 sendo um domínio. Nome de usuário que eu queria mapear para o UID (que eventualmente resolvi em de uma forma completamente diferente), mas eu poderia fazer o login com "usera", fazer um "who" ou "id" e ver "userb" OR "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á interface portátil para retornar uma lista de nomes para um UID, então qualquer pessoa espera o mesmo ou um comportamento semelhante entre sistemas ou mesmo aplicativos no mesmo sistema pode ser infelizmente surpreendido.

No Sun (agora Oracle) yp (páginas amarelas) ou NIS (NetworkInformationServices), também há 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 (o exemplo é o id_allocd, gid_allocd - daemons de alocador UID e GID manpage

Uma terceira fonte que pode ser verificada é a documentação do servidor da Microsoft para mapeamento de contas NFS. NFS é um protocolo de compartilhamento de arquivos unix e eles descrevem como as permissões e o acesso aos arquivos são mantidos pelo ID. Lá, eles escrevem:

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

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

Embora alguns sistemas operacionais possam ter permitido vários nomes/UID (derivados do BSD, talvez?), A maioria dos sistemas operacionais depende disso ser exclusivo e pode se comportar de forma imprevisível quando não é.

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

2
Astara

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 parecia quebrar nada e parecia tornar o manuseio das permissões mais fácil do que teria acontecido com várias contas.

1
Zoredache

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 mais tarde foi associado a um domínio do Active Directory usando winbind. Nesse ponto, o servidor Informix DB não pôde mais ser iniciado. A execução de oninit estava falhando com uma mensagem de erro informando que um "Must be a DBSA to run this program".

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

  1. Corrida id root ou getent passwd 0 (para resolver 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 estava aparentemente contando com uma comparação de string para verificar se o nome de usuário textual do usuário que o iniciava era "root" e, caso contrário, falharia.

  3. Sem winbind, id root e getent passwd 0 retornaria 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 mais uma vez foi resolvido de forma consistente para "root" e o Informix pôde ser iniciado.

Espero que isso seja útil para alguém.

0
Daibhi O Domhnaill