Porque é não está no caminho por padrão?

63

Em sistemas semelhantes ao UNIX ao longo dos anos (o mais relevante para mim, Linux), notei que .(dir atual) nunca está no $PATHpadrão. Por que é isso?

Lembro-me de ler anos atrás que era um problema de segurança, mas o artigo que li não explicava exatamente qual era o problema. É porque alguém poderia deixar uma versão maliciosa lsou cpem um diretório e eu acabaria executando-a sem perceber que ela estava lá?

bash path dirtside
fonte
6
Não é tanto para proteção interativa do usuário, mas também para outros programas (e scripts) que executam outros programas. Até alguns usuários mais experientes gostam de saber que, quando estão em um diretório aleatório, lsserá /usr/bin/lsou ./lsnão. Há também o obstáculo de que, se você souber como adicionar .um final ao seu caminho, provavelmente terá alguma ideia do que está fazendo. O root nunca deve estar .no caminho, muitos sistemas nem deixam mais o logon raiz.
msw

Respostas:

41

Você respondeu corretamente sua própria pergunta, é exatamente por isso que o ponto não está no caminho:
para se proteger contra vírus infantis ou erros honestos.

Obviamente, essa é uma medida antivírus muito inútil e inútil, e nada impede você de adicionar um ponto ao caminho.

harrymc
fonte
13
É engraçado, porém, que você está protegido contra isso, mas não a partir de um arquivo solitário -rfno diretório (torna rm *interessante) ;-)
Joey
A resposta do Unix: por que você nomeou um arquivo -rfem primeiro lugar? ;)
msw
2
@ msw: Outra resposta do Unix é que normalmente o ponto no caminho é desaprovado para contas de administrador, mas é aceitável para não-administradores.
harrymc
o risco seria bastante reduzido se o caminho atual fosse o último , para que todos os locais normais dos programas fossem verificados primeiro ?
Jon z
11
@ Jonz: Na verdade não. Mas o risco é pequeno se o computador estiver livre de vírus. E se o computador estiver infectado, com os vírus modernos, o caminho é a menor das suas preocupações.
21917 harrymc
4

Sim. Se você colocar o "." no caminho, você acabaria enviando muitas chamadas de comando para os arquivos em seu diretório atual.

Mesmo que tenha sido o último, ainda existe um erro piloto. Por exemplo, o Solaris 10 não possui "top". Eu digito "top" no meu sistema o dia todo, porque acho que estou em um sistema que tem "top".

benc
fonte
1

Desculpe, gostaria de fazer isso na forma de um comentário para a resposta selecionada, mas ainda não tenho nenhum representante no superusuário.

A resposta de segurança faz sentido, mas se você colocar "." no PATH como a última coisa, o shell não deve procurar no diretório atual por último enquanto procura por executáveis ​​e, assim, reduzir o risco de segurança? Se ele pesquisasse $ PATH em ordem, encontraria / bin / ls antes de encontrar ./ls.

Então, quão inseguro é para mim colocar "." no final da minha variável de ambiente $ PATH?

Funciona como eu sugiro. Aqui está como eu testei:

Primeiro, adicione "." até o final da sua variável de ambiente PATH.

Em seguida, coloque o seguinte arquivo em algum diretório, como ~ / dir1 / dir2 / test_which.rb:

#!/your/path/to/ruby

puts "this file is from the current directory"

E coloque este arquivo em /usr/bin/test_which.rb

#!/your/path/to/ruby

puts "this file is at /usr/bin/test_which.rb"

Certifique-se de chmod + x dos arquivos para que sejam executáveis.

Agora, se você alterar o diretório para ~ / dir1 / dir2 e executar test_which.rb, obterá a saída

this file is at /usr/bin/test_which.rb

De fato, se você executar "what test_which.rb" de qualquer lugar, ele deverá reportar

/usr/bin/test_which.rb

Você ainda pode executar o arquivo no diretório atual digitando:

./test_which.rb
Tyler Collier
fonte
8
Ninguém nunca cometeu um erro de digitação, como dcou slou sduoem um shell, e foi salvo por "comando não encontrado". Sempre.
Daniel Beck
11
Concorde com Daniel: você pode ter um script malicioso com o nome de um comando com erros ortográficos. Veja também esta resposta .
Ignis
@DanielBeck, você deve tentar usar o alias para erros de digitação. Eu tenho minha configuração preferida de ls(saída colorida e muito mais) com alias à lqual dispensa inteiramente erros de digitação.
Karl Damgaard Asmussen
11
@KarlDamgaardAsmussen kl
deworde
Eu pessoalmente não adiciono '.' para o meu caminho. Não é tão difícil digitar ./run ou o que eu quiser fazer no diretório local. Isso me salvou algumas vezes de pegar coisas inesperadas. Tomate tomahto.
Michael Mathews
1

Mais do que um risco de segurança, ter '.' no PATH torna quase impossível garantir que a execução de qualquer comando atue como pretendido. Pense em executar um comando como 'zip' em um diretório enorme contendo milhares de arquivos com nomes aleatórios. A possibilidade de um deles ser realmente chamado de 'zip' não é desprezível e levaria a um erro que é muito difícil de entender (na verdade, o arquivo deve ser executável, o que, no entanto, pode acontecer).

Em particular, isso é verdade ao escrever scripts que mantêm a variável PATH do usuário. Um bom script escrito deve lidar com todos os casos de canto (como nomes de arquivos com espaços neles ou começando com '-'). Mas é impraticável impedir que um arquivo no diretório atual seja executado em vez de um comando do sistema ...

Emanuele Paolini
fonte