/ usr / bin / vim vs. / bin / vim

Question

Eu obtenho os binários podem estar em lugares diferentes . O que eu não entendo é por que quando eu executo whereis , which e type ele diz que vim está em /usr/bin/vim , mas quando eu tento executá-lo usando sudo ele diz que não posso execute /bin/vim .

Eles não são links e seu conteúdo é o mesmo. Mas eu tenho permissão para executar sudo em /usr/bin/vim , que não está sendo chamado e não tenho idéia do porquê!

[user@host conf.d]$ sudo vim test.conf
[sudo] password for user: 
Sorry, user user is not allowed to execute '/bin/vim test.conf' as root on host.domain.com.br.
[user@host conf.d]$ whereis vim
vim: /usr/bin/vim /usr/share/vim /usr/share/man/man1/vim.1.gz
[user@host conf.d]$ which vim
/usr/bin/vim
[user@host conf.d]$ type vim
vim is /usr/bin/vim
[user@host conf.d]$ ll /bin/vi*
-rwxr-xr-x. 1 root root  910040 Jun 10 03:56 /bin/vi
lrwxrwxrwx. 1 root root       2 Set 30 11:38 /bin/view -> vi
-rwxr-xr-x. 1 root root 2289656 Jun 10 03:56 /bin/vim
lrwxrwxrwx. 1 root root       3 Set 30 12:14 /bin/vimdiff -> vim
-rwxr-xr-x. 1 root root    2084 Jun 10 03:56 /bin/vimtutor
[user@host conf.d]$ ll /usr/bin/vi*
-rwxr-xr-x. 1 root root  910040 Jun 10 03:56 /usr/bin/vi
lrwxrwxrwx. 1 root root       2 Set 30 11:38 /usr/bin/view -> vi
-rwxr-xr-x. 1 root root 2289656 Jun 10 03:56 /usr/bin/vim
lrwxrwxrwx. 1 root root       3 Set 30 12:14 /usr/bin/vimdiff -> vim
-rwxr-xr-x. 1 root root    2084 Jun 10 03:56 /usr/bin/vimtutor
[user@host conf.d]$ md5sum /usr/bin/vim
e5a9c498add4fa49a39a720a826f954c  /usr/bin/vim
[user@host conf.d]$ md5sum /bin/vim
e5a9c498add4fa49a39a720a826f954c  /bin/vim
[user@host conf.d]$ 

    

Answer 1

Algumas noções básicas sobre caminhos de pesquisa

Quando você executa um comando que não contém barras, como vim , o shell precisa saber qual arquivo (ou shell construído / função) executar. Ele encontra isso seguindo o caminho de pesquisa, definido na variável de ambiente PATH . A variável PATH é uma lista de caminhos separados por dois pontos e o shell procurará o nome do comando em cada um desses caminhos nessa ordem.

Por exemplo, um PATH básico de uma instalação Debian se parece com o seguinte:

/usr/local/bin:/usr/bin:/bin

Nesse caso, você encontra /usr/bin/vim primeiro, conforme mostrado pela saída de which vim e type vim .

Agora, quando você executar um comando via sudo , onde as opções env_reset e secure_path são especificadas, sudo redefinirá o caminho de pesquisa para o conteúdo de secure_path antes de executar o comando que você passa. Isso significa que um comando executado por meio de sudo poderia ter um caminho de pesquisa diferente e poderia encontrar um executável diferente da execução direta do comando.

Por exemplo, um% básicosudo PATH do Debian:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Seu cenário

O que eu suspeito que está acontecendo aqui é o seu secure_path especifica uma ordem em que /bin vem antes de /usr/bin ou o último não existe. Nesse caso, o shell procurará vim e, eventualmente, encontrará /bin/vim , desde que ele exista. E se apenas /usr/bin/vim estiver na lista de permissões, o primeiro não poderá ser executado.

Você pode verificar seu atual PATH com echo $PATH . Você pode verificar o sudo de PATH com sudo env | grep PATH . Se o seu administrador tiver definido listas de permissão somente permitindo vim , você poderá acessar sudo vim e executar o comando :echo $PATH .

Você deve conseguir contornar isso especificando um caminho absoluto, por exemplo, sudo /usr/bin/vim .

Por que o search_path existe?

Quanto a por que sudo define um caminho diferente, considere este cenário de ataque:

Seu PATH é apenas uma variável de ambiente. Pode ser definido de muitas maneiras diferentes, possivelmente invisíveis para o usuário. Você pode ter diretórios inseguros que permitem que qualquer um escreva para eles. Se alguém criar um arquivo executável mal-intencionado chamado algo como ls , quando você executar ls , estará executando esse arquivo em vez do ls real.

Mas o dano seria limitado ao que sua conta tem acesso. Agora, digamos que você execute sudo ls - se o PATH for retirado do seu atual PATH em vez de ser redefinido, você executará agora um executável mal-intencionado com privilégios de root - um ataque de escalonamento de privilégios. Muito mais dano possível do que apenas correr como seu próprio usuário.

Agora, você pode argumentar que um invasor com a capacidade de colocar arquivos no seu PATH ou modificar seu PATH já pode causar muitos danos. E você provavelmente está certo. Há opiniões de ambos os lados sobre a utilidade de secure_path , que não vou abordar aqui.