Meu entendimento dos UIDs é que é um número inteiro positivo exclusivo atribuído por um sistema operacional semelhante ao Unix para cada usuário. Cada usuário é identificado no sistema pelo seu UID, e os nomes de usuários são geralmente 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:~#
Eu adicionei dois usuários com o mesmo UID e GID: test12 e 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.
Eu fiquei confuso sobre qual é o propósito disso, e isso pode afetar permissões e logs de usuários, etc. Então, agora se um usuário é adicionado com uid=0 e gid=0 terá privilégios como uma conta root?
A resposta aqui é que o Linux não protege você de você mesmo.
Se você realmente quiser su root e entrar nos arquivos / etc e fornecer a todos os usuários o mesmo UID, você pode. É apenas um arquivo de texto.
Mas você realmente não deveria e isso terá consequências indesejadas.
Existem razões válidas para isso. Por exemplo, eu costumava trabalhar em um laboratório onde cada um de nós tinha nosso próprio computador, mas nosso $HOME estava em uma unidade compartilhada exportada por um servidor. Então, meu $HOME foi
/users/terdon
Como a pasta /users não estava na minha máquina local, mas exportada via NFS, para qualquer análise que fosse pesada em E / S, usaria os dados armazenados em meus 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 era todo o sistema e um que era 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 se eu estava logado como terdon ou como localuser e a maneira como nosso sysadmin implementou isso era dando localuser e terdon o mesmo UID . Dessa forma, eu poderia manipular livremente meus arquivos locais, independentemente de qual usuário eu estava logado no momento.
Dois usuários podem ter o mesmo UID, pois é apenas um número em um arquivo de texto para que você possa defini-lo como quiser, incluindo um valor já usado. Como você viu, porém, isso não é uma boa idéia.
Sistemas Unix & amp; O Linux geralmente não faz nada para proibir duplicatas no arquivo /etc/passwd . A intenção desse arquivo é associar um UID a um nome físico que pode ser exibido por ferramentas de linha de comando, como ls , quando o usuário está listando os 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
A outra finalidade deste arquivo é especificar qual shell um usuário obterá quando fizer 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 arquivo /etc/passwd do sistema:
$ getent passwd r00t
r00t:x:0:0:root:/root:/bin/bash
$ getent passwd toor
toor:x:0:0:root:/root:/bin/bash
O papel do arquivo /etc/passwd é NÃO significa apenas rastrear contas de usuários. A função de rastrear nomes de usuário e senhas é de responsabilidade do arquivo /etc/shadow . Arquivos como /etc/passwd e /etc/group são realmente destinados a fornecer um nome legível quando seu sistema está listando arquivos de discos.
Lembre-se de que seus arquivos são gravados no disco usando os nomes não reais do 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 realmente gravados no disco!
Na verdade, é bastante comum ter dois usuários com o mesmo ID. No FreeBSD, geralmente há dois usuários com o UID 0: root e toor. Root usa o shell / bin / sh embutido e toor usa um shell diferente, geralmente bash.
No Linux, todos os usuários e grupos são na verdade apenas números. Isso é o que a saída do comando id que você postou mostra.
O arquivo /etc/passwd mapeia os nomes dos usuários para os IDs (números) e no exemplo fornecido, você simplesmente mapeou dois nomes de usuário para o mesmo usuário ID.
Efetivamente, você criou um usuário, test12 , ID 1005, que também tem 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 seria test12
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ários 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 no arquivo.
Mas o que você criou é uma situação confusa para outros administradores de sistemas; evite mudando o UID de test13
Se isso mudasse, então quebraria os sistemas em que os administradores tivessem um uso para esse recurso (veja o exemplo de Terdon). Então, isso nunca foi mudado, e eu acho que nunca será.
Originalmente, havia apenas os arquivos passwd e group, e eles serviam ao seu propósito. não havia nenhum comando adduser , nenhum addgroup , os arquivos foram editados pelo root usando vi ou ed.
Houve algumas peculiaridades!
Para lembrar o próximo ID de usuário, era comum que os administradores tivessem um usuário especial como a última linha que tinha um nome de usuário de ! (porque ! era um nome de usuário inválido) e essa entrada foi usada para armazenar o próximo ID do usuário. Crude, eu admito, mas funcionou! Então, por que quebrar um intestino, tornando-o mais complicado, semelhante ao desenvolvimento ágil de hoje.
Houve falhas conhecidas. O principal é que tinha que ser legível em todo o mundo, para que utilitários como ls pudessem mapear user-id => name . Isso significa que qualquer um pode 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 , muitas vezes estes foram ignorados, porque eles eram inconsistentes entre os Unixes, então a maioria das pessoas apenas continuou com a edição manual.
Demorou alguns anos, antes que o arquivo de senha shadow fosse inventado, isso fornecia um pouco mais de segurança, ocultando as senhas criptografadas. Mais uma vez, apenas complexidade suficiente foi adicionada, mas ainda era bastante grosseira e simples. Os utilitários useradd e groupadd foram introduzidos, o que manteve shadow e shadow- atualizados. Para começar, estes eram frequentemente invólucros simples de script de shell em torno de utilitários adduser / addgroup proprietários de vendedores. Mais uma vez, foi apenas o suficiente para continuar.
Redes de computadores estavam crescendo, pessoas trabalhando em vários de uma vez para realizar trabalhos, então o admin dos arquivos passwd/group estava se tornando um pesadelo, especialmente com o NFS, então vem as Páginas Amarelas também 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 quisesse um sistema de autenticação centralizado, seguro, exclusivo, com 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. Nós ainda não precisávamos de todos os sinos e assobios. Eu acho que a filosofia tinha mudado um pouco até agora, "Se você fosse fazer melhor, você não iria usá-lo" , então não se preocupe com isso.
É por isso que não acho que o simples arquivo passwd irá mudar. Não há mais nenhum motivo, e é ótimo para aqueles Raspberry Pi de 30 libras com 2 talvez 3 de temperatura de monitoramento do usuário e feeds do Twitter. OK, você só precisa ser um pouco cuidadoso com seu ID de usuário, se você quiser algo único, e não há nada que impeça o entusiasta de colocar useradd em um script que primeiro seleciona o próximo ID único de um banco de dados (arquivo) para definir um id único, se é isso que você quer. É open source depois de tudo.
Existem identificadores que o sistema operacional espera ser exclusivo, mas eles são usados para rastrear o hardware. O conhecimento de que um Identificador Exclusivo Universal específico corresponde a um disco rígido contendo arquivos de sistema pode ajudá-lo a continuar operando se a configuração do hardware alterar. A Microsoft chama esses identificadores globais exclusivos e os usa para rastrear todo o software do Windows. Ironicamente, essas siglas foram mal escolhidas.
Do ponto de vista do sistema operacional, a maioria das alterações no identificador de usuários e grupos equivale a alterar sua interface externa. Poderia funcionar normalmente apesar de colisões; principalmente o que é exigido dos usuários e grupos do sistema é que eles existem. Não pode saber o que os usuários exigem. Em situações como essa, a filosofia do Unix é que o sistema operacional deve assumir que os administradores saibam o que estão fazendo e devem ajudá-los a fazê-lo rapidamente.
O arquivo /etc/passwd apenas mapeia nomes de usuários simbólicos para o userID real. Se você fizer deliberadamente dois nomes simbólicos que mapeiam para um userID, ele permitirá que você.
Isso não significa que seja uma boa ideia realmente fazê-lo. Algumas pessoas podem ter encontrado casos de uso muito específicos, nos quais podem aproveitar esse recurso, mas, em geral, você não deve fazer isso.
Linux (e outros UNIXes) tomam a opinião de que o administrador sabe o que está fazendo. Se você disser para fazer algo estúpido, então a culpa é sua, da mesma maneira que se você disser ao seu carro para dirigir sobre um penhasco, você não pode ir aos fabricantes e perguntar por que o carro permitiu que você fizesse isso. / p>
Tags user-management