Estou tentando encontrar o motivo correto para a pergunta feita. Meu entendimento é que:
sudoprecisa ler o/etc/sudoersarquivo que só pode ser lido pelo root, e é por isso que ele precisa ser definido como root UIDsuvai criar um novo shell com um UID real e efetivo diferente e precisa verificar a senha. Para verificar a senha, ele precisa ler/etc/shadow, e é por isso que ele precisa ser definido como root UID. Depois de verificar a senha, ele precisaria chamarsetuid()o processo bifurcado e, para usar um argumento UID arbitrário, seu processo pai deve ter root como UID efetivo, então isso também é outro motivo.
As razões acima estão corretas?
Suas razões estão corretas em sua maioria, mas em ambos os casos (
suesudo), a razão básica pela qual eles precisam ser executados como root, é que eles precisam poder alterar os vários identificadores de usuário e grupo do processo atual. Isso envolve chamar funções comosetreuid, que só funcionam para usuários e grupos arbitrários se o processo de chamada estiver sendo executado como root.Ambos
suesudotêm outros recursos que também exigem execução como root, mas são detalhes efetivamente secundários quando comparados aos acima. Como você mencionou,sudoprecisa ler/etc/sudoers; mas o fato de que o último é legível apenas pelo root não é um requisito difícil. Ambos os programas podem usar o PAM para realizar a autenticação, mas normalmente também incluem fallbacks que exigem a capacidade de ler/etc/shadow, que também é legível apenas pelo root. A lista continua; mas isso realmente não importa, pois o fato inevitável é que a capacidade de alterar usuários e/ou grupos é dada apenas ao root, e é por isso quesuelessudosão setuid root.Como funcionam os internos do sudo? e as questões relacionadas fornecem informações adicionais.