Por que posso criar usuários com o mesmo UID?

Meu entendimento dos UIDs é que é um número inteiro positivo único atribuído por um sistema operacional do tipo Unix a cada usuário. Cada usuário é identificado no sistema por seu UID, e os nomes de usuário geralmente são usados ​​apenas como uma interface para humanos.

Como dois usuários podem ter o mesmo UID, isso não é um conflito para o meu sistema e pacotes?

root@kdc:~# id test12
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~# id test13
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~#

Adicionei dois usuários com o mesmo UID e GID: test12e test13

A saída de /etc/passwd:

client@kdc:~$ cat /etc/passwd | grep test12
test12:x:1005:1000::/home/test12:/bin/sh
client@kdc:~$ cat /etc/passwd | grep test13
test13:x:1005:1000::/home/test13:/bin/sh

Eu adicionei os usuários por useradd -ou 1005 -g1000 username.

Fiquei confuso qual é o objetivo disso, e isso pode afetar as permissões e os logs do usuário, etc. Então agora, se um usuário for adicionado uid=0e gid=0tiver privilégios como uma conta root?

A resposta aqui é que o Linux não protege você de si mesmo.

Se você realmente deseja su rootacessar os arquivos / etc e fornecer a todos os usuários o mesmo UID, é possível. É apenas um arquivo de texto.

Mas você realmente não deveria e terá conseqüências não intencionais.

Na verdade, existem razões válidas para isso. Por exemplo, eu costumava trabalhar em um laboratório em que cada um de nós tinha um computador, mas o nosso $HOMEestava em uma unidade compartilhada exportada por um servidor. Portanto, a minha $HOMEera

/users/terdon

Como a /userspasta não estava na minha máquina local, mas foi exportada pelo NFS, para qualquer análise pesada de E / S, eu usaria os dados armazenados nos discos rígidos locais para não sobrecarregar a rede do laboratório. Para esse fim, eu, e todos os outros, tínhamos dois usuários: um que abrangia todo o sistema e outro local para a máquina em questão. A casa do usuário local era

/home/localuser

No entanto, eu precisava ter acesso total aos meus arquivos, independentemente de estar logado como terdonou como localusere como nosso administrador de sistemas implementou isso, fornecendo o mesmo localusere terdono mesmo UID. Dessa forma, eu poderia manipular livremente meus arquivos locais, independentemente de qual usuário estava atualmente conectado.

Dois usuários podem ter o mesmo UID porque é apenas um número em um arquivo de texto, para que você possa configurá-lo para o que quiser, incluindo um valor que já seja usado. Como você viu, não é uma boa ideia.

Na verdade, é bastante comum ter dois usuários com o mesmo ID. No FreeBSD, geralmente existem dois usuários com o UID 0: root e toor. O Root usa o shell / bin / sh interno e o toor usa um shell diferente, geralmente o bash.

Sistemas Unix e Linux geralmente não fazem nada para proibir duplicatas no /etc/passwdarquivo. A intenção desse arquivo é associar um UID a um nome físico que possa ser exibido por ferramentas de linha de comando, como lsquando o usuário está listando arquivos.

$ ls -n | head -5
total 986000
drwxrwxr-x.   3 1000 1000      4096 Feb 13 19:51 1_archive_sansa
-rw-rw-r--.   1 1000 1000    760868 Dec 16 08:21 2.18.x Database Scheme.jpg
-rw-rw-r--.   1 1000 1000       972 Oct  6 20:26 abcdefg
drwxrwxr-x.   2 1000 1000      4096 Feb 11 03:34 advanced_linux_programming

O outro objetivo deste arquivo é especificar qual shell o usuário obterá quando efetuar o login.

$ getent passwd saml
saml:x:1000:1000:saml:/home/saml:/bin/bash

Um vetor de ataque comum em sistemas do tipo Unix é adicionar linhas como estas ao /etc/passwdarquivo do sistema :

$ getent passwd r00t
r00t:x:0:0:root:/root:/bin/bash

$ getent passwd toor
toor:x:0:0:root:/root:/bin/bash

A função do /etc/passwdarquivo NÃO se destina apenas a rastrear contas de usuário. A função de rastrear nomes de usuário e senhas é de responsabilidade do /etc/shadowarquivo. Arquivos como /etc/passwde /etc/groupsão realmente destinados a fornecer um nome legível por humanos quando o sistema estiver listando arquivos de discos.

Lembre-se de que seus arquivos são gravados no disco usando nomes não reais de UID / GID.

$ stat afile 
  File: ‘afile’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd02h/64770d    Inode: 6560621     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    saml)   Gid: ( 1000/    saml)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2014-02-27 15:54:21.852697029 -0500
Modify: 2014-02-27 15:54:21.852697029 -0500
Change: 2014-02-27 15:54:21.852697029 -0500
 Birth: -

Observe o Uid:e Gid:, os números são o que realmente está gravado no disco!

No Linux, todos os usuários e grupos são na verdade apenas números. É o que idmostra a saída do comando que você postou.

O /etc/passwdarquivo mapeia nomes de usuário para IDs de usuário (números) e, no exemplo que você forneceu, você simplesmente mapeou dois nomes de usuário para o mesmo ID de usuário.

Efetivamente, você criou um usuário, test12ID 1005, que também possui um segundo nome de usuário test13. No entanto, o sistema mapeará o UID 1005 para o primeiro nome de usuário encontrado, o que seriatest12

O Linux "permite" que você faça isso porque não há sistema para impedir que você faça isso. /etc/passwdé apenas um arquivo de texto, os nomes de usuário são mapeados para o UID encontrado para sua entrada nesse arquivo, os UIDs são mapeados para o primeiro nome de usuário encontrado nesse arquivo.

Mas o que você criou é uma situação confusa para outros administradores de systams; evite alterando o UID detest13

A razão pela qual isso é permitido hoje é simplesmente porque o sistema não o impede.

Se isso mudasse, os sistemas onde os administradores tinham uso para esse recurso seriam interrompidos (veja o exemplo de Terdon). Portanto, nunca foi alterado, e acho que nunca.

Originalmente, havia apenas os arquivos passwd e group, e eles serviram a seu propósito. não havia nenhum comando adduser , nenhum addgroup , os arquivos foram editados pela raiz usando vi ou ed.

Houve algumas peculiaridades!

Para lembrar o próximo ID de usuário a ser usado, era comum os administradores terem um usuário especial como a última linha que tinha um nome de usuário !(porque !era um nome de usuário inválido) e essa entrada foi usada para armazenar o próximo ID do usuário. Bruto, admito, mas funcionou! Então, por que quebrar o intestino, tornando-o mais complicado, semelhante ao desenvolvimento ágil hoje?

Havia falhas conhecidas. O ser principal, que tinha que ser legível pelo mundo, para que utilitários como lspudessem mapear user-id => name. Isso significava que qualquer um podia ver a senha criptografada de todos e todos os usuários e IDs no sistema.

Alguns sistemas Unix começaram a introduzir alguns scripts de shell adduser addgroup, geralmente esses foram ignorados, porque eram inconsistentes entre os Unixes; portanto, a maioria das pessoas continuou a edição manual.

Demorou alguns anos, antes que o shadowarquivo de senha fosse inventado, isso fornecia um pouco mais de segurança, ocultando as senhas criptografadas. Mais uma vez, foi acrescentada complexidade suficiente, mas ainda assim era bastante grosseira e simples. Os utilitários useradde groupaddforam introduzidos, que foram mantidos shadowe shadow-atualizados. Para começar, esses eram geralmente simples invólucros de scripts de shell em torno dos utilitários proprietários adduser / addgroup dos fornecedores . Mais uma vez, foi apenas o suficiente para continuar.

As redes de computadores estavam crescendo, as pessoas trabalhavam em várias de uma vez para realizar tarefas, de modo que a administração dos passwd/grouparquivos estava se tornando um pesadelo, especialmente com o NFS; assim, as Páginas Amarelas também são conhecidas como NIS para aliviar o fardo.

Estava se tornando óbvio agora que algo um pouco mais flexível era necessário e o PAM foi inventado. Portanto, se você fosse realmente sofisticado e desejasse um sistema de autenticação centralizado, seguro e com identificação única, todos os sinos e assobios, você chamaria um servidor central para autenticar, talvez um servidor Radius, servidor LDAP ou Active Directory.

O mundo cresceu. Mas os arquivos passwd / group / shadow ainda permaneciam para nós, usuários / desenvolvedores / laboratórios menores. Ainda não exigimos realmente todos os sinos e assobios. Eu acho que a filosofia havia mudado um pouco até agora, "Se você iria melhorar, você não usaria nada" , então não se preocupe.

É por isso que acho que o arquivo passwd simples nunca será alterado. Não há mais razão, e é ótimo para aqueles Raspberry Pi de £ 30 com 2 talvez 3 temperaturas de monitoramento de usuários e feeds do twitter. OK, você só precisa ter um pouco de cuidado com seus IDs de usuário, se quiser que sejam exclusivos, e não há nada para impedir que o entusiasta agrupe useradd em um script que primeiro selecione o próximo ID exclusivo de um banco de dados (arquivo) para definir um ID único, se é isso que você deseja. É de código aberto, afinal.

O /etc/passwdarquivo apenas mapeia nomes de usuário simbólicos para o ID do usuário real. Se você deliberadamente criar dois nomes simbólicos que mapeiam para um ID do usuário, ele permitirá.

Isso não significa que é uma boa ideia fazê-lo. Algumas pessoas podem ter encontrado casos de uso muito específicos nos quais podem tirar proveito desse recurso, mas em geral você não deve fazê-lo.

O Linux (e outros UNIXes) consideram que o administrador sabe o que está fazendo. Se você disser para fazer algo estúpido, a culpa é sua, da mesma maneira que se você disser que seu carro dirige por um penhasco, não poderá ir aos fabricantes e perguntar por que o carro permitiu que você fizesse isso.

Existem identificadores que o sistema operacional espera serem únicos, mas são usados ​​para rastrear o hardware. O conhecimento de que um determinado identificador universalmente único corresponde a um disco rígido contendo arquivos do sistema pode ajudá-lo a continuar operando se a configuração do hardware for alterada. A Microsoft chama esses identificadores globalmente exclusivos e os usa para rastrear todos os softwares do Windows. Ironicamente, essas siglas foram mal escolhidas.

Da perspectiva do sistema operacional, a maioria das alterações de identificador de usuário e grupo equivale a alterar sua interface externa. Poderia funcionar normalmente apesar das colisões; principalmente o que é exigido dos usuários e grupos do sistema é que eles existem. Ele não pode saber o que os usuários precisam. Em situações como essa, a filosofia do Unix é que o sistema operacional deve assumir que os administradores sabem o que estão fazendo e ajudá-los a fazê-lo rapidamente.

Encontrei algumas evidências que apóiam a resposta de @ andybalholm.

No APUE , §8.15:

Qualquer processo pode descobrir seu ID do usuário real e eficaz e o ID do grupo. Às vezes, porém, queremos descobrir o nome de login do usuário que está executando o programa. Poderíamos chamar getpwuid( getuid()), mas e se um único usuário tiver vários nomes de login, cada um com o mesmo ID de usuário? ( Uma pessoa pode ter várias entradas no arquivo de senha com o mesmo ID do usuário para ter um shell de login diferente para cada entrada .) O sistema normalmente controla o nome em que efetuamos login (Seção 6.8), egetlogin função fornece uma maneira para buscar esse nome de login.

....

Dado o nome de login, podemos usá-lo para procurar o usuário no arquivo de senhas - para determinar o shell de login, por exemplo - usando getpwnam.

Btw, gostaria de saber se é possível mudar para outro shell enquanto estiver conectado.