A página ArchWiki - rsnapshot menciona a criação de vários usuários com uide gidconfigurado 0como um meio de criar usuários que fazem login remotamente para realizar backups.
Uma coisa que você pode fazer para mitigar o dano potencial de uma violação do servidor de backup é criar usuários alternativos nas máquinas clientes com uid e gid definidos como 0, mas com um shell mais restritivo, como scponly.
Presumo que o objetivo seja conceder a essas contas as permissões de leitura, gravação e execução do rootusuário, com a condição de que seu shell de login lhes conceda direitos reduzidos.
Isso significa que mesmo que as contas tenham o mesmo gide uidainda sejam distinguidas pelo nome da conta e tenham o mesmo gide uidlhes dêem os mesmos direitos de acesso que?
No que diz respeito aos privilégios no sistema operacional, todos os privilégios estão associados a UIDs e GIDs, não a nomes. Assim, se alguém tiver UID 0 (no modelo Unix tradicional), ele é root e possui todas as permissões associadas a ele, independente do nome usado para efetuar login.
No entanto, ao fazer login remotamente, você pode ter vários nomes de usuário para o mesmo ID e fornecer shells diferentes para cada usuário. Como os bancos de dados Unix passwd e shadow tradicionais armazenam o shell e outras informações por nome de usuário, se você especificar um nome de usuário alternativo para UID 0, como
toor(uma alternativa comum em alguns sistemas), o shell e a senha listados no banco de dados para esse usuário serão ser consultado para determinar os privilégios de acesso e o shell a ser usado. Assim que o login for bem-sucedido, o OpenSSH ou o processo de login alterará o usuário e o grupo para os IDs fornecidos e executará o shell especificado.Depois que o login ocorrer, o processo ainda terá privilégios de root, mas o shell em execução poderá permitir acesso apenas a um conjunto limitado de programas. Supondo que o shell seja realmente restrito e não permita outros acessos, é possível limitar o acesso dessa forma. No entanto, qualquer comprometimento desse shell (digamos, devido a um bug) permitirá a execução com privilégios de root.
Existem algumas circunstâncias em que os nomes de usuário são levados em consideração, principalmente durante o login: o nome de usuário determina a entrada do usuário ( por exemplo, from
/etc/passwd) que é levada em consideração e quaisquer grupos secundários ( por exemplo, from/etc/group).Vários usuários podem compartilhar um determinado uid e/ou gid primário, mas ainda ter diferentes shells e grupos secundários. Uma vez definidos os uid e os gids de uma determinada sessão, isso normalmente é tudo o que importa — os processos têm uids e gids, e não nomes de usuários e grupos. As permissões são determinadas pelo ID, não pelo nome.
Costumava ser comum que os sistemas tivessem várias contas de id 0: uma com um shell normal e outra com um shell de resgate vinculado estaticamente. Contas de backup id 0, capazes de copiar qualquer arquivo, também não são inéditas (como você mencionou). Ambos os casos de uso estão ficando mais raros; logins diretos de root são incomuns, os sistemas de recuperação não precisam de shells estáticos e os sistemas de backup baseados em pull tendem a depender de daemons.