Como os daemons são executados com uma conta de usuário com um shell inválido?

Question

Estive pesquisando todo o Google tentando encontrar uma resposta para isso e tentando mentalmente analisar os scripts de inicialização para descobrir onde isso é feito, sem sucesso.

Acabei de fazer um ps e fiz um exemplo aleatório. Eu tenho um processo que aparece da seguinte forma:

polkitd 1230 1 0 May07 ? 00:00:00 /usr/lib/polkit-1/polkitd --no-debug

olhando para o meu / etc / passwd, vejo:

polkitd:x:87:87:PolicyKit daemon owner:/var/lib/polkit:/bin/false

Como teste, executo um comando como root: %código% Que não retorna nenhuma saída, como esperado devido a ter / bin / false como um shell. Além disso, # su - polkitd -c whoami não me muda para o polkitd. Para ter certeza de que estava fazendo isso corretamente, testei ambos com uma conta de usuário normal e os dois funcionaram como deveriam.

Então, como é que uma conta dedicada como o polkitd no meu exemplo pode ser feita para executar um processo, quando você aparentemente não consegue executá-la manualmente?

    

Answer 1

root pode se tornar polkitd por meio de uma chamada de sistema apropriada, por exemplo seteuid(2) como pode ser demonstrado com

$ cat becomepolkit.c 
#include <sys/types.h>
#include <stdio.h>
#include <unistd.h>

int main(void)
{
    // ID obtained via 'id polkitd' on a Centos7 system
    // other systems may vary
    seteuid(999);

    printf("look for %d in process list\n", getpid());

    sleep(99999);

    return 0;
}
$ make becomepolkit
cc     becomepolkit.c   -o becomepolkit
$ sudo ./becomepolkit &
[1] 10914
$ look for 10915 in process list

$ ps auwwx | grep '1091[5]'
polkitd  10915  0.0  0.0   4160   340 pts/0    S    22:46   0:00 ./becomepolkit
$ 

Normalmente, root através do sistema init (por exemplo, systemd ) ou cron iniciará um processo como root e, em seguida, alterará o usuário do processo; nenhum acesso ao shell é necessário para que isso aconteça. Você pode observar isso para um processo arbitrário executando o processo em strace ou alguma outra ferramenta de rastreamento:

sudo strace -o blah ./becomepolkit
look for 10968 in process list
^C$ grep 999 blah
setresuid(-1, 999, -1)                  = 0
nanosleep({99999, 0}, {99997, 670178798}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
$ 

Então aqui o Linux está realmente usando a chamada setresuid(2) mas a mesma diferença, o processo aparecerá como polkitd na tabela de processos.

    

Answer 2

O shell de login de um usuário é o programa que a maioria dos programas de login invoca quando o usuário é autenticado (geralmente inserindo seu nome e senha). Os programas de login incluem login (para efetuar login em um console de texto), sshd (para efetuar login na rede), su (para efetuar login de outra conta), etc.

Os programas de login podem optar por executar o que quiserem. O fato de a maioria deles executar o shell de login do usuário é uma decisão administrativa mais do que uma restrição técnica. Uma classe de programas de login que não segue essa convenção são os gerenciadores de exibição, ou seja, programas que fazem o login do usuário no modo gráfico: eles geralmente executam um script /bin/sh , como /etc/X11/Xsession .

Os serviços do sistema geralmente não são invocados pelos programas de login. Eles são chamados automaticamente por um ativador de daemon que está sendo executado com privilégios administrativos; Iniciar um serviço do sistema não requer autenticação. (Para que um usuário solicite iniciar um serviço do sistema normalmente requer autenticação, para se tornar root.) Portanto, o shell de login não está envolvido, não haveria motivo para envolvê-lo.

Lançadores de daemon (minha terminologia para o propósito desta resposta) incluem systemd , start-stop-daemon , runuser , etc.