Considere um sistema Linux com instalação e configuração padrão de sudo; ou seja, rootpode executar todos os comandos, pegando a identidade de outros usuários, e por favor considere o seguinte comando:
sudo -u user1 -g group1 some_program
Claro, eu esperaria que fosse some_programexecutado com EUID user1 e com EGID group1. No entanto, aprendi da maneira mais difícil que isso só funciona se user1for realmente um membro de group1; Eu realmente deveria ter estudado man sudomais a fundo. Da explicação da -gopção de linha de comando:
[...] A política sudoers permite que qualquer um dos grupos do usuário alvo seja especificado por meio da opção -g, desde que a opção -P não esteja em uso.
Isso é muito inconveniente. Costumo usar sudopara fins de teste, especialmente quando um serviço ou programa é executado sob UIDs e GIDs arbitrários, o respectivo usuário não sendo membro do respectivo grupo. Nesses casos, antes de poder testar com sudo, tenho que tornar o respectivo usuário membro do respectivo grupo e não devo esquecer de reverter essa ação quando os testes terminarem.
Daí a pergunta: Existe uma configuração ou configuração que permite root-executar sudoprogramas usando UIDs e GIDs arbitrários que não correspondem ? Estou interessado apenas em soluções que forneçam um mecanismo geral para todos os programas, UIDs e GIDs . Ou seja, colocar listas de programas específicos, UIDs ou GIDs /etc/sudoersnão é uma opção.
Uma solução possível poderia ser um provedor de políticas alternativo sudoque permitisse isso. No entanto, aprender a instalá-lo e configurá-lo provavelmente seria muito difícil, e não tenho certeza se seguiria esse caminho, mesmo que não houvesse outra solução. Além disso, eu não encontrei tal coisa até agora.
ATUALIZAÇÃO 1 (2022-01-27)
O sistema em questão roda o Debian buster, atualizado com todos os patches disponíveis no momento em que este artigo foi escrito. O SELinux não está instalado. Este é o meu /etc/sudoersarquivo (deixando apenas comentários e linhas vazias):
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
root ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL
ipupdate ALL = (root) NOPASSWD: /root/scripts/asterisk-external-ip
Atualmente acredito que a última linha não tem nada a ver com o problema e que provavelmente deveria tê-la removido para minimizar a distração. Por outro lado, aprendi que às vezes são apenas as partes aparentemente sem importância "removidas para maior clareza" que realmente causam o respectivo erro.
Executar um programa em um grupo-alvo diferente é o ponto principal da
-gopção. E não há restrição na combinação-ucom-g.Não é explicado claramente, mas o que esta frase está se referindo é o que o sudo permite que você faça fora da caixa, o que não é o objetivo de usar o sudo. Sudo é útil com políticas adicionais
sudoersno arquivo, e elas podem permitir conjuntos arbitrários de usuários e grupos.Root não recebe nenhuma permissão especial. Se você pode executar
sudo -u user1como root ou como usuário “sudoer”, é porque existe uma regra no arquivo sudoers que permite isso. Por algum motivo (talvez porque o mantenedor nunca pensou em atualizá-lo), nosudoersarquivo de amostra, essa regra éIsso só permite o uso de
sudo -u, não desudo -g, exceto o uso limitado de-gpara especificar o grupo primário entre os grupos que o usuário já possui. Para permitir a elevação de privilégios de grupo, bem como privilégios de usuário, altere essas regras (ou qualquer que seja o equivalente em seu sistema, por exemplo, com%adminou%sudooubinarusetc.)Este é o padrão em algumas distribuições, por exemplo Debian.