Início / unix / Perguntas / 532625
Accepted
sourcejedi
Asked: 2019-07-29 11:32:42 +0800 CST

Por que o Debian executa "atd" como o usuário "daemon"?

  • 772
$ ps -aux|grep atd
daemon     800  0.0  0.1  27964  2228 ?        Ss   19:11   0:00 /usr/sbin/atd -f
alan-sy+  7042  0.0  0.0  12780   948 pts/0    S+   20:22   0:00 grep atd

$ /sbin/getpcaps 800
Capabilities for `800': = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read+p

$ ls -l /usr/sbin/atd
-rwxr-xr-x 1 root root 22536 Dec  8  2016 /usr/sbin/atd

# /lib/systemd/system/atd.service
[Unit]
Description=Deferred execution scheduler
Documentation=man:atd(8)

[Service]
ExecStart=/usr/sbin/atd -f
IgnoreSIGPIPE=false

[Install]
WantedBy=multi-user.target

atversão do pacote é 3.1.20-3.

Por que atdcair para o daemonusuário? Isso não acontece no Fedora Linux 30.

atdainda precisa manter todos os recursos, pois pode aceitar solicitações de qualquer usuário e executar tarefas como esse usuário, incluindo root.

O daemonusuário não deve ser usado. Os daemons individuais devem usar suas próprias contas de usuário, se necessário, para limitar os comprometimentos de segurança. ( Provavelmente não importa neste caso, porque o kernel não permite que usuários não-root manipulem processos que retêm qualquer capacidade de root).

debian users

1 respostas

  1. Best Answer

    Isso provavelmente se deve à história e à diferença de opinião entre os autores do LSB e os mantenedores do Debian envolvidos. A base-passwddocumentação no Debian diz sobre o daemonusuário :

    Alguns daemons sem privilégios que precisam ser capazes de gravar em alguns arquivos no disco são executados como daemon.daemon ( portmap, atd, lambdamoo, mone outros). Daemons que não precisam possuir nenhum arquivo às vezes são executados como none.nogroup; geralmente é uma prática melhor usar um usuário dedicado, e daemons mais complexos ou preocupados com a segurança certamente fazem isso. O usuário daemon também é útil para daemons instalados localmente, provavelmente.

    Também diz que

    O LSB 1.3 lista o daemon como legado e diz: "O 'daemon' UID/GID foi usado como um UID/GID sem privilégios para os daemons executarem a fim de limitar seu acesso ao sistema. Geralmente os daemons agora devem ser executados sob UID/ GIDs para particionar ainda mais os daemons uns dos outros."

    No entanto, em geral, a documentação do Debian permite que o daemonusuário seja usado.

    atdfoi alterado para usar daemon:daemonem vez de root em 2005 , quando o LSB 1.3 já estava disponível há alguns anos. Imagino que mudar de root para daemonfoi percebido como uma redução suficiente no privilégio, foi mais simples do que adicionar um usuário dedicado (o que pode ter envolvido a administração na época) e como você diz provavelmente não importa neste caso ...

    O bug vinculado acima fornece o seguinte raciocínio para descartar para daemon, ou melhor, para um usuário não root (o bug sugeriu um grupo dedicado ...):

    O crontab do Debian foi recentemente modificado para executar o setgid crontab em vez do setuid root. Como as necessidades do at são substancialmente semelhantes, ele provavelmente poderia funcionar da mesma maneira, e um programa setuid-root a menos na base seria uma coisa boa.

    • 1

relate perguntas