Eu tenho a tendência de endereçar isso permitindo que o processo que executa o servidor, neste caso o servidor web, execute o comando relevante, e somente esse comando, via sudo sem senha.
Por exemplo, aqui está a minha entrada sudoers para permitir que um usuário chamado NAGIOS (que executa meu servidor de monitoramento local) execute um plug-in que verifica esse hardware RAID como root:
nagios ALL=(root) NOPASSWD: /usr/lib/nagios/plugins/check_md_raid
Você teria algo semelhante, talvez:
apache ALL=(root) NOPASSWD: /sbin/service dnsmasq restart
Para resolver suas preocupações acima, isso não permite que qualquer pessoa que possa subverter o processo do apache execute sudo bash
, sudo shutdown -h now
ou mesmo sudo service dnsmasq stop
. Ele permite exatamente o que é especificado no arquivo sudoers.
É verdade que, se o comando service
estiver mal escrito e alguém puder encontrar uma maneira de executar service dnsmasq stop
como root via sudo, altere o modo no arquivo passwd
ou inicie uma% de permissão.sshd
na porta 22222, ou mesmo fazer qualquer coisa nefasta, então você tem um problema. Mas, nesse caso, você tem um problema, no entanto, você executa o comando de serviço como root , seja via sudo ou qualquer outro mecanismo. sudo
faz o melhor para higienizar o ambiente, e o comando de serviço é um componente da maioria dos GNU / Linuxes (e já existe há algum tempo) e, portanto, provavelmente não tem falhas óbvias.
Executar o comando service
via passwordless sudo
não é menos seguro do que qualquer outro método de executá-lo, e provavelmente mais seguro do que muitas formas caseiras ou outras menos testadas.