Une faille dans Bash ?
Kirils Solovjovs vient de mettre en évidence un comportement de Bash un peu bizarre. En effet, dans certaines conditions, le shell a tendance à interpréter des noms de fichiers comme des arguments. Voici quelques explications.
On crée quelques dossiers et fichiers :
$ mkdir -p test && cd test
$ mkdir rep1 rep2
$ touch fichier1 fichier2
Si on liste le contenu, on les retrouve sans problème :
$ ls
fichier1 fichier2 rep1 rep2
Maintenant, on crée deux fichiers spécifiques et on observe le résultat :
$ touch -- -r -f
$ ls
-f fichier1 fichier2 -r rep1 rep2
On s'aperçoit que les fichiers -f et -r sont présents. Et ils peuvent être dangereux s'ils sont interprétés comme des arguments. On fait le test avec la commande rm et l'option -i qui permet de demander une confirmation avant suppression :
$ rm -i *
$ ls
-f -r
Et là bingo. Le shell Bash les interprète bien comme des arguments, et au lieu de faire un rm -i, il fait carrément un rm -rf.
Bon cette faille n'est pas très dangereuse en elle-même, peu de gens feront cette erreur. Il faut quand même avoir l'idée de créer des fichiers nommés "-r" et "-f" avec la commande touch. Mais cela laisse un peu perplexe sur le comportement de Bash, qui ne fait pas la différence entre un nom de fichier et un argument.
Créé en 2005, Tux-planet est un site qui a pour ambition de regrouper des articles sur Linux et le monde des logiciels libres. 
10 Commentaires pour "Une faille dans Bash ?"
Flux des commentaires de cet article Ajouter un commentaireOn peux éviter les problèmes avec ça:
rm -i ./*
@Keul, ou avec ça:
rm -- *
(tout ce qui est après -- n'est plus traité comme un argement)
C'est très très vieux ça. Ça faisait même partie des critiques d'Unix de l'"Unix Haters Handbook" (google it) en 1994...
C'est pas spécifique a bash d'ailleurs, mais a tout les shells, et c'est pas vraiment une "faille" non plus.
Certains créent même des fichiers "-i" dans tous leurs dossiers pour éviter les problèmes de rm *
Un nom de fichier est finalement un argument comme un autre pour le programme. Ce n'est donc pas un souci spécifique à bash qui se comporte "normalement" à ce niveau.
Le problème ne vient pas de bash mais de la commande rm.
bash comme tout interpréteur de commandes Unix se contente de remplacer * par la liste des fichiers dans le répertoire courant et de la passer en argument à rm.
C'est la commande rm qui interprète -r -f comme des options.
Si on veut que tous les arguments soient interprétés comme des noms de fichiers, il faut utiliser
rm -- *
@ou ça : justement, je me demandais à quoi pouvait servir le double tiret. Maintenant je sais.
@Adrien : faut être fou pour mettre des fichiers -i dans ses répertoires.
@Netsurfeur : visiblement, il n'y pas que la commande rm qui se comporte comme ça. La commande cat aussi.
Pourtant, tu a utilisé le double tiret dans la commande touch... tu n'a pas RTFM?
@Keul : non, j'ai copié bêtement les commandes du mail de Kirils Solovjovs, en me disant, tiens c'est bizarre le double tiret !
Le -- marche partout (bash, ksh, sh et surement d'autres)
pour les curieux, tester les commandes suivantes :
set a b
echo $*
echo $#
set -- -a -b -c
echo $*
echo $#
set -a -b -c
Oui, de base si tu connais -- pour le touch tu sais forcément l'utiliser pour le rm...
Et puis bash n'a aucune idée des paramètres de chaque appli, une appli prend un tableau de chaînes sans distinction, point barre. Bash aurait une faille si il réinterprétait les noms de fichiers ($;\,\t ).
D'ailleurs l'étoile n'est utile que lorsque l'on travaille à la main, et donc que l'on sait ce qu'on manipule, pour les scripts c'est plus compliqué (pb d'ifs, de caractères interdits, de fichiers cachés, de réinterprétation...).