
Estou tentando encontrar o motivo correto para a pergunta declarada. Meu entendimento é que:
sudo
precisa ler o/etc/sudoers
arquivo que só pode ser lido pelo root, e é por isso que ele precisa ser set-UID rootsu
vai criar um novo shell com um UID real e efetivo diferente e precisa verificar a senha. Para verificar a senha, ela precisa ser lida/etc/shadow
, por isso precisa ser set-UID root. Depois de verificar a senha, seria necessário chamarsetuid()
o processo bifurcado e, para usar um argumento UID arbitrário, seu processo pai deve ter root como UID efetivo, portanto, isso também representa outro motivo.
As razões acima estão corretas?
Responder1
Seus motivos estão em sua maioria corretos, mas em ambos os casos ( su
e sudo
), o motivo básico pelo qual eles precisam ser executados como root é que eles precisam ser capazes de alterar os vários identificadores de usuário e grupo do processo atual. Isso envolve chamar funções comosetreuid
, que só funciona para usuários e grupos arbitrários se o processo de chamada estiver sendo executado como root.
Ambos su
e sudo
possuem outros recursos que também requerem execução como root, mas são efetivamente detalhes secundários quando comparados aos anteriores. Como você mencionou, sudo
precisa ler /etc/sudoers
; mas o fato de este último ser legível apenas pelo root não é um requisito difícil. Ambos os programas podem usar PAM para realizar autenticação, mas normalmente também incluem substitutos que exigem capacidade de leitura /etc/shadow
, que também só pode ser lida pelo root. A lista continua; mas isso realmente não importa, já que o fato inevitável é que a capacidade de alterar usuários e/ou grupos é dada apenas ao root, e é por isso que su
e sudo
são setuid root.
Como funcionam os componentes internos do sudo?e as questões relacionadas fornecem informações adicionais.