Como o 'sudo' procura o caminho dos executáveis?

Question

Estou usando rubygems (1.3.7) com gemas que exigem privilégios de root no Ubuntu 10.10. Quando eu comparo minha configuração para um Ubuntu 9.10 com a instalação do rubygems 1.3.6, vejo a seguinte diferença em gem environment :

1.3.7 / 10.10 - EXECUTABLE DIRECTORY: /var/lib/gems/1.8/bin

1.3.6 / 09.10 - EXECUTABLE DIRECTORY: /usr/bin

A saída é a mesma se eu uso sudo ou não. Para corrigir isso (não sei por que é diferente em primeiro lugar), tentei modificar minha variável de caminho.

A minha pergunta é, onde sudo procura executáveis? Se eu instalar uma gem (usando sudo ), o executável é colocado no caminho /var , obviamente. Eu adicionei este caminho aos meus arquivos ~/.profile e /etc/environment , mas não consigo obter sudo para executar os executáveis.

Se eu correr:

• $ gemname executa a ferramenta corretamente.
• $ sudo gemname apenas me diz command not found .
• $ sudo echo $PATH it faz mostrar o caminho correto.
• $ sudo -i gemname é executado corretamente.
• $ sudo sudo -V mostra que o PATH está preservado.

Será que sudo honra ~/.profile e / ou /etc/environment ? Em caso afirmativo, eles não podem encontrar meu executável enquanto o diretório é mostrado na variável de ambiente $PATH ?

Eu li a documentação de sudo , também pesquisei e examinei vários tópicos sobre stackoverflow e serverfault (por exemplo Como substituir uma variável de ambiente PATH em sudo? , mas meu exemplo mostra que $PATH contém o caminho correto), mas eles nunca realmente mostram como executar uma joia via sudo .

    

Answer 1

Note que, em seu terceiro comando, seu shell expande $PATH antes que o sudo consiga vê-lo, e assim a saída é o caminho do seu shell, não o PATH que o sudo vê. O que você quer é algo como sudo echo \$PATH ou sudo sh -c 'echo $PATH' .

Além disso, dê uma olhada na seção NOTAS DE SEGURANÇA da página sudo(8) man. Acredito que o Ubuntu construa sudo com a opção de compilação SECURE_PATH. Procure a linha "Valor para substituir o $ PATH do usuário por" na saída de sudo sudo -V .

sudo -i simula um login inicial e, portanto, lê arquivos como .profile (embora quais arquivos ele leia depende do shell do root). Sem -i , ele herda as variáveis de ambiente preservadas do ambiente de seu interlocutor, com o saneamento da PATH que mencionei acima.

Por que o caminho mudou em primeiro lugar, eu suspeito que a mudança foi uma escolha deliberada por parte dos desenvolvedores. Veja mais discussões sobre bugs.debian.org .

    

Answer 2

Vamos por partes:

• gemname, ele executa a ferramenta corretamente.

Tudo bem:)

• gem gemdo meramente me diz que o comando não foi encontrado.

gemname não está no seu $PATH

• sudo echo $ PATH mostra o caminho correto.

Isso é legal: a expansão da variável acontece antes que o bash execute o programa. Então, quando você executa isso, ele expande para seu usuário $PATH antes chamando sudo, então a linha que é passada para o sudo é mais parecida com:

$ sudo echo "/usr/bin:/bin:"

• sudo -i gemname é executado corretamente.

sudo -i é executado como um shell de login e homenageia .profile e / ou .login . Como na página man diz:

It also initializes the environment, leaving DISPLAY and TERM unchanged, setting HOME, MAIL, SHELL, USER, LOGNAME, and PATH, as well as the contents of /etc/environment on Linux and AIX systems. All other environment variables are removed.