Pourquoi est-ce . pas dans le chemin par défaut?

63

Au fil des années, sur les systèmes de type UNIX (principalement pour Linux), j'ai remarqué que .(répertoire actuel) n'est jamais dans le $PATHdéfaut. Pourquoi est-ce?

Je me souviens avoir lu il y a des années qu'il s'agissait d'un problème de sécurité, mais l'article que j'ai lu n'expliquait pas exactement le problème. Est-ce parce que quelqu'un pourrait laisser une version malveillante de lsou cpdans un répertoire et que je finirais par l'exécuter sans me rendre compte qu'il était là?

bash path du côté
la source
6
Ce n'est pas tant pour la protection interactive des utilisateurs que pour les autres programmes (et scripts) qui en exécutent d'autres. Même certains utilisateurs avertis aiment savoir que, lorsqu'ils se trouvent dans un répertoire aléatoire, ce lssera /usr/bin/lsou ./lsne sera pas. Il y a aussi l'obstacle de si vous savez comment ajouter .à la fin de votre chemin, vous avez probablement une idée de ce que vous faites. root ne devrait jamais avoir .dans le chemin, beaucoup de systèmes ne laissent même plus la connexion root.
msw

Réponses:

41

Vous avez répondu correctement à votre propre question. C’est précisément pour cette raison que dot n’est pas sur la bonne voie:
pour se protéger contre les virus enfantins ou les erreurs honnêtes.

Bien sûr, il s’agit d’une mesure anti-virus très boiteuse et inutile, et rien ne vous empêche d’ajouter vous-même un point au chemin.

harrymc
la source
13
C'est drôle, cependant, que vous soyez protégé contre cela, mais pas contre un fichier isolé -rfdans le répertoire (ce qui est rm *intéressant) ;-)
Joey
La réponse Unix: pourquoi avez-vous nommé un fichier -rfen premier lieu? ;)
msw
2
@msw: Une autre réponse Unix est que normalement le point dans le chemin est mal vu pour les comptes d'administrateur, mais est correct pour les non-administrateurs.
harrymc
le risque serait-il grandement réduit si le chemin actuel était le dernier , de sorte que tous les emplacements normaux des programmes soient vérifiés en premier ?
Jon z
1
@ Jonz: Pas vraiment. Mais le risque est assez faible si votre ordinateur est exempt de virus. Et si l'ordinateur est infecté, avec les virus modernes, le chemin est le moindre de vos soucis.
harrymc
4

Oui. Si vous mettez le "." dans le chemin, vous finirez par envoyer de nombreux appels de commande aux fichiers de votre répertoire actuel.

Même si c'était la dernière fois, il y a toujours une erreur du pilote. Par exemple, Solaris 10 manque de "top". Je tape "top" sur mon système toute la journée, car je pense que je suis sur un système qui a "top".

benc
la source
1

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

La réponse de sécurité est logique, mais si vous mettez "." Dans votre PATH comme dernière chose, le shell ne devrait-il pas regarder dans le répertoire en cours en dernier lorsqu'il cherche des exécutables, et réduire ainsi le risque de sécurité? Si elle cherchait $ PATH dans l'ordre, elle trouverait / bin / ls avant de trouver ./ls.

Alors, à quel point il m'est incertain 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, tel que ~ / dir1 / dir2 / test_which.rb:

#!/your/path/to/ruby

puts "this file is from the current directory"

Et mettez ce fichier à /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 en ~ / dir1 / dir2 et exécutez test_which.rb, vous obtiendrez le résultat

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

En effet, si vous exécutez "quel test_which.rb" de n'importe où, il devrait signaler

/usr/bin/test_which.rb

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

./test_which.rb
Tyler Collier
la source
8
Personne n'a jamais fait de faute de frappe, telle que dcou slou sduodans un shell, et a été enregistré par "commande non trouvée". Déjà.
Daniel Beck
1
D'accord avec Daniel: vous pourriez avoir un script malveillant nommé d'après une commande mal orthographiée. Voir aussi cette réponse .
Ignis
@ DanielBeck, vous devriez essayer d'utiliser un alias pour les fautes de frappe. J'ai ma configuration préférée de ls(sortie couleur et autres) avec un alias lqui évite entièrement les fautes de frappe.
Karl Damgaard Asmussen le
1
@KarlDamgaardAsmussen kl
deworde
Personnellement, je n'ajoute pas '.' sur mon chemin. Ce n'est pas si difficile de taper ./run ou ce que je veux faire dans le répertoire local. Cela m'a évité à quelques reprises de détecter des choses inattendues. Tomate tomahto.
Michael Mathews
1

Plus qu'un risque de sécurité, avoir '.' dans PATH, il est presque impossible de s’assurer que l’exécution d’une commande agit comme prévu. Pensez à exécuter une commande comme "zip" dans un énorme répertoire contenant des milliers de fichiers avec des noms aléatoires. La possibilité que l'un d'entre eux s'appelle réellement «zip» n'est pas négligeable et entraînerait une erreur très difficile à comprendre (en réalité, le fichier doit être exécutable, ce qui peut toutefois arriver).

Ceci est particulièrement vrai lors de l'écriture de scripts qui conservent la variable PATH de l'utilisateur. Un bon script écrit doit traiter de tous les cas de figure (comme les noms de fichiers contenant des espaces ou commençant par '-'). Mais il n’est pas pratique d’empêcher l’exécution d’un fichier du répertoire en cours au lieu d’une commande système ...

Emanuele Paolini
la source