Como os daemons funcionam?

Question

Se um usuário quiser executar um comando, ele deve primeiro efetuar login em um sistema. Mas alguns usuários no sistema têm /bin/false ou /sbin/nologin definido como um shell padrão no arquivo /etc/password . Se eu alterar /bin/bash para /bin/false no caso do meu usuário, não poderei fazer login no sistema, portanto, também não poderei executar comandos.

Mas os usuários sem shell fazem isso de qualquer maneira:

# ps -eo "%mem,user,group,args" | grep -i dns
 0.0 dnscrypt dnscrypt /usr/sbin/dnscrypt-proxy --daemonize --user dnscrypt --local-address=127.0.0.1:53 --resolver-address=208.67.222.222:443 --provider-name=2.dnscrypt-cert.opendns.com --provider-key=B735:1140:206F:225D:3E2B:D822:D7FD:691E:A1C3:3CC8:D666:8D0C:BE04:BFAB:CA43:FB79

# cat /etc/passwd | grep -i dns
dnscrypt:x:113:121::/home/dnscrypt:/bin/false

Como um usuário sem um shell pode executar um comando?

    

Answer 1

No POSIX, todo processo em execução possui três User IDs (UIDs) associados a ele; o UID real , que identifica o usuário que iniciou o processo, o UID efetivo , que é usado para determinar quais recursos o processo pode acessar e o conjunto salvo -User-ID (SUID), que é o UID efetivo que o processo teve quando foi iniciado (no ponto da última chamada exec() ). Destes, o UID efetivo é o mais significativo, pois é o usado para determinar as decisões de controle de acesso em relação ao processo.

Os daemons geralmente são iniciados a partir de scripts init, que são executados pelo sistema init, sendo executados com privilégios de root. Os processos podem alterar o UID real / efetivo através da setuid() , seteuid() e setreuid() . Este é o caso com a invocação de dnscrypt-proxy fornecida como um exemplo ¹ na questão. A opção --user dnscrypt informa dnscrypt-proxy para assumir a identidade do usuário dnscrypt . Um processo privilegiado pode assumir a identidade de qualquer usuário (mesmo alterando seu SUID salvo), enquanto processos de usuários não privilegiados podem apenas definir o UID efetivo para o ID do usuário real, o UID efetivo ou o ID do usuário definido salvo.

Os casos de uso básicos para alterar os UIDs são para um processo privilegiado para descartar seus privilégios, permanentemente ou temporários. O último caso é necessário para programas com o conjunto SUID bit , que precisa executar alguns operações sem privilégios usando seu UID real e, em seguida, recupere seus privilégios concedidos pelo SUID. O padrão POSIX.1-1990 adotou o comportamento tradicional do System V para a função setuid() , que especifica setuid() para se comportar de maneira diferente para usuários com privilégios e sem privilégios. Quando o chamador tinha o privilégio apropriado, a função definia o processo de chamada 'UID real, UID efetivo e SUID salvo. Quando o chamador não tem o privilégio apropriado, a função define apenas o UID efetivo, conforme descrito acima.

Por outro lado, o 4.3BSD não suporta o SUID salvo, mas manipula o último caso com funções separadas. Enquanto setuid() sempre configurava os UIDs real e efetivo, seteuid() poderia ser usado para definir apenas o UID efetivo (como setuid() em POSIX1-1990 para usuários não privilegiados). Por último, setreuid() permitiu que os processos trocassem seus UIDs reais e efetivos, para suportar processos com privilégios anteriores para recuperar seus privilégios.

O padrão POSIX: 2001 introduziu um recurso obrigatório chamado _POSIX_SAVED_IDS. Isso permite que um aplicativo SUID alterne seu UID efetivo entre os valores de seu SUID salvo e o ID de usuário efetivo. Mais informações podem ser encontradas na seção lógica da POSIX : Especificação de 2004 para setuid() . No Linux, a setuid() é implementada como a versão POSIX com o recurso _POSIX_SAVED_IDS.

^{1: ps pode ser feita para exibir o UID real, o UID efetivo e o SUID salvo com os especificadores de formato ruser , euser e suser , por exemplo, ps -eo "ruser,euser,suser,args" .}