Est-il prudent d'ajouter. à mon chemin? Comment venir?

49

J'ai vu des personnes mentionner dans d' autres réponses qu'il est une mauvaise idée d'inclure le répertoire de travail actuel (' .') dans votre $PATHvariable d'environnement, mais je n'ai pas été en mesure de trouver une question traitant spécifiquement du problème.

Alors, pourquoi ne devrais-je pas ajouter .à mon chemin? Et si malgré tout, je le fais quand même, à quoi dois-je faire attention? Est-il plus sûr de l'ajouter à la fin qu'au début?

path

— Jander
source

5

unix-faq: Qu'est-ce qui ne va pas avec '.' dans votre $ PATH

— Evgeny Vereshchagin

39

Si vous êtes le seul utilisateur de la machine, tout va bien, à condition de savoir ce que vous faites. La préoccupation générale est que, en ayant votre répertoire actuel dedans PATH, vous ne pouvez pas voir les commandes comme une liste constante. Si vous devez exécuter un script / programme à partir de votre répertoire actuel, vous pouvez toujours l'exécuter explicitement en ajoutant ./son nom au début (vous indiquez au système "Je veux exécuter ce fichier à partir de mon répertoire actuel").

Dites, maintenant vous avez tous ces petits scripts sur votre système de fichiers; un jour, vous courrez le mauvais à coup sûr. Donc, avoir votre PATHliste prédéfinie de chemins statiques est une question d'ordre et d'économiser vous-même d'un problème potentiel.

Toutefois, si vous allez ajouter .à votre PATH, je vous suggère annexant à la fin de la liste ( export PATH=$PATH:.). Au moins, vous ne remplacerez pas les fichiers binaires du système de cette manière.

Si vous êtes une racine sur le système et ont le système exposé aux comptes d'autres utilisateurs, ayant .en PATHest un énorme risque de sécurité: vous pouvez cdà certains répertoire de l' utilisateur, et exécuter involontairement un script malveillant seulement parce que vous avez mal saisi une chose ou d'un script qui a le même nom qu'un binaire à l'échelle du système.

— artyom
source

1

+ Acceptez la théorie sous-jacente et indiquez que les problèmes peuvent toujours exister même lorsque vous êtes le seul utilisateur du système. Les deux réponses soulèvent d'excellents points. J'ajouterai que chaque fois que vous partagez des répertoires avec un autre utilisateur, le risque est accru, que vous soyez root ou non.

— Jander

6

Même en tant que seul utilisateur sur la machine: chaque fois que vous extrayez un goudron non approuvé, il peut en placer un lsdans votre répertoire en cours. Ensuite, vous exécutez lspour inspecter les fichiers extraits et vous avez déjà exécuté le code malveillant.

— Lesmana

35

Le risque est que quelqu'un mette dans le répertoire un fichier exécutable malveillant qui se trouve être votre répertoire actuel.

Le pire des cas se produit lorsque:

vous êtes connecté en tant que root car la commande malveillante a un pouvoir de dégâts illimité
.se trouve au début de votre PATH car les commandes standard peuvent être remplacées sans que vous le remarquiez (généralement une commande lsqui pourrait se cacher de la liste).

Le risque est beaucoup plus faible si vous êtes connecté en tant qu'utilisateur régulier et que vous avez le .à la fin de votre PATH mais qu'il existe toujours:

quelqu'un pourrait découvrir que vous tapez souvent une commande avec une erreur et en installer une correspondante
quelqu'un pourrait installer une fausse commande avec le nom d'une autre qui n'est pas installée.

Notez que dans tous les cas, le risque existe toujours, même si vous êtes le seul utilisateur de la machine. Un logiciel malveillant serait installé si, par exemple, vous extrayiez une archive téléchargée depuis un site compromis.

— jlliagre
source

15

Installez slpour voir à quelle fréquence le point 3 se produit.

— Jordanie

ou alias l=`ls`.

— Anko

ça n'a pas besoin d'être méchant. Je m'attends lsà obtenir une liste de répertoires, mais certains projets que je télécharge peuvent avoir un lsscript dans leur dossier de projet racine comme raccourci vers autre chose. lsest probablement un mauvais exemple, mais je peux certainement imaginer epour modifier, dpour déboguer, mpour faire, bpour construire. J'en ai moi-même à l'échelle mondiale. Si je tape, mj'attends que make lance (mon raccourci), pas un script local appelé mà exécuter.

— gman

@gman Droite. Une commande non malveillante peut avoir involontairement des effets indésirables. Notez que les commandes / alias à une seule lettre étaient mal vus depuis la création d’Unix en raison du risque élevé de faute de frappe. Les rares standards sont wet [.

— Jlliagre

3

Même si vous êtes toujours très prudent avec ce que vous tapez, mettre .dans votre PATH, même à la fin, n'est toujours pas sûr car certains programmes changent le répertoire courant en /tmp(qui est accessible en écriture) et peuvent également essayer d'exécuter des utilitaires qui ne sont pas installés, donc par défaut à ce qui est dans /tmp. Si cela se produit, c'est un vecteur d'attaque.

Notez également qu'il n'y a pas inconvénient beaucoup d'éviter .dans PATH, car il ./est facile de le type (en particulier sur les claviers comme QWERTY, où ces personnages sont sur les touches consécutives et ne nécessitent pas Shift) et l' utilisation ./sera également la fin de l' aide, de frappes potentiellement sauver à la fin.

Si vous voulez vraiment pouvoir taper des commandes à partir du répertoire courant, les shells modernes (comme zsh, avec son command_not_found_handler) peuvent fournir des fonctionnalités permettant de le faire en toute sécurité, c'est-à-dire vous permettant d'ajouter tous les contrôles de sécurité souhaités dans le gestionnaire, avant la fin du processus. commande est exécutée.

— vinc17
source