O que você faz quando tenta sudo e o PATH do root se torna kerblooey?

Question

Eu tenho a sensação de que algo ruim aconteceu com essa máquina.

faheem@bulldog:/usr/local/src/mercurial$ sudo dpkg -i 
mercurial_3.0-1_amd64.deb mercurial-common_3.0-1_all.deb    
dpkg: warning: 'ldconfig' not found in PATH or not executable 
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable 
dpkg: error: 2 expected programs not found in PATH or not executable 
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin
and /sbin

Esta é uma velha máquina não-mantida que eu tenho usado por um tempo. Assumindo que ia morrer algum dia. Parece que este pode ser o dia. Começando a lançar erros um pouco mais cedo, e parece que alguém apenas reiniciei.

ATUALIZAÇÃO: depois de executar

sudo -s

Eu verifiquei o valor do caminho

echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/games

Então, algumas coisas estão faltando aqui, por exemplo sbin e /usr/sbin .

UPDATE 2:

Como se constata, pessoas ou pessoas desconhecidas excluíram as seguintes linhas de /etc/sudoers .

Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Obrigado a Anthony por explicar.

    

Answer 1

Como a "Nota:" na parte inferior das suas dicas sudo dpkg -i de saída, isso geralmente é causado por $PATH sendo definido errado. Uma maneira que acontece é quando você executa dpkg -i sem raiz; mas esse não é o caso aqui.

Uma maneira fácil de confirmar o caminho é rodar sudo -s , que diz ao sudo para rodar um shell ao invés de algum outro programa. Então você vai ser desembarcado em um prompt de shell de root. Se você for echo "$PATH" , provavelmente encontrará /sbin e / ou /usr/sbin em falta.

O comportamento padrão do sudo é manter a variável $PATH do usuário intacta. Esse padrão é normalmente alterado pelo padrão /etc/sudoers do Debian, que contém:

Defaults        env_reset
⋮
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Se você não tiver a linha secure_path , isso explicaria o problema.

Duas opções são adicionar essa linha de volta (mas alguém pode tê-la removido porque queria que o caminho do usuário fosse transportado, por exemplo, porque ele contém elementos extras em /opt , por exemplo) ou para adicionar /sbin:/usr/sbin para o usuário $PATH .