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à?
Réponses:
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.
-rfdans le répertoire (ce qui est rm *intéressant) ;-)
-rfen premier lieu? ;)
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".
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.rbEn effet, si vous exécutez "quel test_which.rb" de n'importe où, il devrait signaler
/usr/bin/test_which.rbVous pouvez toujours exécuter le fichier dans le répertoire actuel en tapant:
./test_which.rbdcou slou sduodans un shell, et a été enregistré par "commande non trouvée". Déjà.
ls(sortie couleur et autres) avec un alias lqui évite entièrement les fautes de frappe.
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 ...
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.