Por que o PATH é redefinido em um comando sudo? [duplicado]

Question

Depois de muito contato frustrante com a parede de tijolos, descobri isso:

$ echo $PATH
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/steve/bin

$ sudo bash
# echo $PATH
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin

mas

$ sudo bash -c 'echo $PATH'
/sbin:/bin:/usr/sbin:/usr/bin

$ sudo bash -Ec 'echo $PATH'
/sbin:/bin:/usr/sbin:/usr/bin

Eu obtenho o outro post que o caminho sudo é lido de /etc/sudoers - mas por quê? Configurar $PATH em /root/.profile faz algum sentido, ou isso é apenas uma receita para a confusão acima (isto é, gerar um shell real faz com que um $PATH diferente do usado nos comandos casuais sudo ...)?

Estou usando o bash no RHEL 6.4.

    

Answer 1

Proteções

sudo tem proteções incorporadas que você está percebendo quando executa vários desses comandos. Essas proteções estão fazendo várias coisas, como impor um $PATH seguro.

Do arquivo /etc/sudoers :

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

Isso é o que está sendo exibido quando você executa seus comandos sudo -c .... . Você pode desativar esse comportamento com a opção -E para sudo .

NOTA: Para algumas configurações, a opção -E não funcionará. Para "remediar", você pode usar sudo env "PATH=$PATH" bash . Isso também levará seu atual $PATH para o seu ambiente sudo .

interativo vs. login

Quando você executou este comando:

$ sudo bash

Você executou um shell bash interativo versus um login bash shell. Isso tem a ver com como bash origina seus arquivos de configuração.

• interativo, também conhecido como bash ou bash -i , fontes $HOME/.bashrc
• login, também conhecido como bash -l , fontes $HOME/.bash_profile

Então, por que o -E não funciona?

A resposta de TylerRick a essa pergunta SO (sudo muda PATH - por quê?) abrange muitas das razões pelas quais . O principal é que ele é tipicamente codificado quando sudo é compilado, como é o caso do Ubuntu, resultando nesses switches como inúteis. Houve longos problemas em aberto no Launchpad em relação a eles e eles nunca foram corrigidos, deixando-nos com a percepção de que a Canonical acha melhor deixar esse comportamento como padrão.

• bug do Ubuntu # 50797 ("sudo criado com --with-secure-path é problemático" )
• Erro do Ubuntu # 192651 ("o caminho do sudo é sempre reinicializado")
• bug do Ubuntu # 226595 ("impossível manter / especificar o PATH")

Answer 2

Quando uma regra em sudoers autoriza um usuário a executar um comando específico wibble , geralmente é necessário definir PATH como um valor seguro: um que contenha apenas diretórios em que o usuário não possa plantar seus próprios programas. Se wibble chamou o comando externo foo e PATH não foi redefinido, o usuário pode colocar ~/bin na frente do seu PATH , vincular /bin/sh a ~/bin/foo e executar sudo wibble para invocar ~/bin/foo , o que permite que ele digite comandos de shell arbitrários.

A reinicialização do PATH é, portanto, um padrão seguro. Embora não seja necessário em todos os casos, é muito mais fácil e seguro tornar essa configuração padrão.

Quando uma regra em sudoers autoriza um usuário a executar comandos arbitrários, a redefinição do PATH não tem vantagem de segurança direta. Há uma vantagem indireta, que é a de que o usuário pode acidentalmente configurar um PATH contendo programas potencialmente prejudiciais, e a reinicialização do PATH evita o risco de que esses programas sejam chamados acidentalmente. Há também uma vantagem funcional: é comum precisar de ter /usr/local/sbin , /usr/sbin e /sbin ao executar comandos como root, mas não tê-los como um usuário comum.

Se você não quiser que o caminho seja redefinido quando você executar sudo , adicione-se ao grupo isento em sudoers :

Defaults exempt_group+=stevebennet

Se você executar um shell de login ( sudo -I ou sudo bash -l ou outro método), esse shell normalmente lê .profile no diretório inicial do usuário de destino e esse arquivo pode alterar o PATH.

    

Answer 3

Isso por motivos de segurança. O PATH está definido para um bem definido e não para qualquer PATH hackeado que o usuário possa ter.

Consulte o link para obter uma solução alternativa.