Você pode executar o programa errado. Alguém poderia fazer você executar o programa deles.
A ação -execdir
executa seu comando no diretório que contém o (s) arquivo (s) encontrado (s). Quando $PATH
contém caminhos relativos, como .
ou qualquer coisa que não comece com /
, -execdir
é inseguro porque existe um diretório onde um arquivo é encontrado (ou outro diretório resolvido em relação a ele) também pode conter um executável com o mesmo nome daquele que você está tentando executar. Esse executável potencialmente não confiável seria executado em vez disso.
Isso pode ser deliberadamente explorado por outro usuário para que você execute o programa, o que pode causar danos ou violar a segurança dos dados, em vez do programa que você está tentando executar. Ou, com menos frequência, pode simplesmente resultar na execução inadvertida do programa errado, mesmo sem ninguém tentar fazer com que o problema aconteça.
Se tudo na sua variável de ambiente PATH
for um caminho absoluto, esse erro não deverá ocorrer, mesmo que o diretório que você está pesquisando e -execdir
ing de esteja contido em PATH
. (Verifiquei se isso funciona.) Se você acredita que não possui nenhum diretório relativo em $PATH
, mas ainda está recebendo este erro, atualize sua pergunta com detalhes, incluindo a saída de echo "$PATH"
.
Um exemplo concreto.
Como exemplo do que poderia dar errado, suponha:
- Alice tem
.
em seu$PATH
porque deseja executar programas em qualquer diretório para o qual ela tenha sidocd
, sem se preocupar em preceder seus nomes com./
. - A vingança de Alice, Eve, compartilhou
/home/eve/shared
com Alice. - Alice deseja estatísticas (linhas, palavras, bytes) nos arquivos
.c
que Eve compartilhou com ela.
Então Alice corre:
find ~eve/shared -name \*.c -execdir wc {} \;
Infelizmente para Alice, Eve criou seu próprio script, nomeou-o como wc
, definiu-o como executável ( chmod +x
) e colocou-o clandestinamente em um dos diretórios em /home/eve/shared
. O script de Eve é assim:
#!/bin/sh
/usr/bin/wc "$@"
do_evil # Eve replaces this command with whatver evil she wishes to do
Então, quando Alice usar find
com -execdir
para executar wc
nos arquivos que Eve compartilhou, e chegar aos arquivos no mesmo diretório que o script wc
personalizado de Eve, wc
run de Eve-- com todos os privilégios de Alice!
(Sendo habilidoso, Eve fez seu script wc
funcionar como um wrapper para o sistema wc
, então Alice nem saberá que algo deu errado, ou seja, que do_evil
foi executado, no entanto, variações mais simples - e também mais sofisticadas - são possíveis.
Como o find
impede isso.
find
impede que esse problema de segurança aconteça recusando-se a executar a ação -execdir
quando $PATH
contiver um diretório relativo.
find
oferece duas mensagens de diagnóstico, dependendo da situação específica.
-
Se
.
estiver em$PATH
, então (como você viu) diz:find: The current directory is included in the PATH environment variable, which is insecure in combination with the -execdir action of find. Please remove the current directory from your $PATH (that is, remove "." or leading or trailing colons)
Ele provavelmente tem uma mensagem especial para o caso
.
, pois é especialmente comum. -
Se um caminho relativo diferente de
.
- digamos,foo
- aparece em$PATH
e você executafind
com-execdir
, ele diz:find: The relative path 'foo' is included in the PATH environment variable, which is insecure in combination with the -execdir action of find. Please remove that entry from $PATH
É melhor não ter caminhos relativos em $PATH
.
O risco de ter .
ou outros caminhos relativos em $PATH
é especialmente aumentado ao usar um utilitário que altera automaticamente o diretório, e é por isso que find
não permite usar -execdir
nessa situação.
Mas ter caminhos relativos, especialmente .
, no seu $PATH
é inerentemente arriscado e é realmente melhor evitar de qualquer maneira. Considere a situação fictícia no exemplo acima. Suponha que, em vez de executar find
, Alice simplesmente cd
s para ~eve/shared/blah
e execute wc *.c
. Se blah
contiver o script wc
de Eve, do_evil
será executado como Alice.