Histórico do UNIX não incluindo o diretório atual em $ PATH

Question

No mundo UNIX, é bem compreendido que você precisa prefixar os binários no diretório atual com ./ para executá-los: . não está em $PATH por padrão. Isso é para evitar binários malvados substituindo os utilitários do sistema como ls e obtendo o código exec.

Eu gostaria de saber a história dessa decisão. Foi no UNIX desde o começo? Certas conchas?

Eu quero ser claro: não estou procurando por motivos em geral porque foi implementado; Eu entendo isso. Estou procurando o evento que causou ou pelo menos quando a alteração foi feita.

Citações seriam muito apreciadas.

Curiosamente, parece que bash pretende incluir . , pelo menos essa é a minha leitura desta fonte (de config-top.h ):

/* The default value of the PATH variable. */
#ifndef DEFAULT_PATH_VALUE
#define DEFAULT_PATH_VALUE \
  "/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:."
#endif

(Alguns questionaram a relevância desta questão. Houve algumas conversas sobre um número de instaladores executáveis em Janelas que são vulneráveis a um ataque similar: executáveis por padrão procurarão por DLLs em . , então plantando uma DLL malvada em Downloads , você tem exec de código, geralmente como admin. aprender história estão condenados a repeti-lo "momento.)

    

Answer 1

Não será tarefa fácil encontrar "documentos históricos" sobre esta decisão, mas citando outra resposta do guarda-chuva do StackExchange, você encontrará o que eu também considero a resposta mais apropriada para sua pergunta: para evitar " sh ## acontece "cenário":

• bash: Por que é. não está no caminho por padrão?

Pergunta:

On UNIX-like systems over the years (most relevantly to me, Linux), I've noticed that . (current dir) is never in the $PATH by default. Why is this? I recall reading years ago that it was a security problem, but the article I read didn't explain what exactly the problem was. Is it because someone could leave a malicious version of 'ls' or 'cp' in a directory, and I'd end up running it without realizing it was there?

Resposta:

You answered correctly your own question, that's exactly why dot isn't in the path: To protect against childish viruses or honest mistakes.

Of course, this is a very lame and useless anti-virus measure, and nothing stops you from adding dot to the path yourself.

E em este link , você pode encontrar um exemplo adicional de por que é perigoso colocar o ponto em $PATH .

Nota de rodapé:

An extreme example would be the situation in which an ordinary user created a shell script such as rm -r /, which would delete all files and directories in the system for which the user had writing permission, and named this script ls. Were the system administrator to navigate to the directory in which this script was located and attempt to run the standard ls command in order to view the contents of that directory, the shell would instead run the script with the same name and thereby remove the contents of all currently mounted partitions on the computer!

Além disso, o propósito do PATH é completar o caminho de um comando de tal forma que você não precise se lembrar ou digitar o caminho completo de seus binários. Não há necessidade de indexar comandos de um diretório em que você esteja. Não é útil se você souber onde esses programas estão armazenados.

EDITAR:

No entanto, depois de algumas pesquisas, descobri que a ideia por trás do caminho de pesquisa vinha das Multics , mas a limitação era que só pesquisou dentro de /bin . O Unix v3 foi o primeiro a implementá-lo sem essa limitação de um diretório. E dando uma olhada nas páginas de segurança do manual a seguir, elas já mostraram quais são os problemas ao usar . em uma variável PATH. Isso se aplica não somente a su e reforça a questão de segurança de injetar código malicioso no ambiente.

• Um leitor Unix de Pesquisa: trechos anotados do Manual do Programador, 1971–1986

Citando a página 13:

Trojan Horse tricks and countermeasures were discovered in an ongoing game that has been recounted by Morris and Fred Grampp. Notice, for example, the removal of login(1) to chapter 8 and the intrusion of /etc/ into the synopsis for su (Grampp, v8). These fillips defeated the old chestnut of leaving programs named login or su lying around in hopes of capturing a password typed by an unwary system administrator. Other subtle features of the modern su: dot is excluded from the shell search path and the burglars’ favorite shell variable IFS is reset.

Desde a sua concepção, esse recurso se mostrou perigoso se usar ponto como parte do $PATH .