- AVERTISSEMENT N'ESSAYEZ PAS DE L'EXÉCUTER SUR UNE MACHINE DE PRODUCTION
En lisant la page Wikipedia sur le sujet je suis généralement ce qui se passe avec le code suivant :
:(){ :|:& };:
extrait de description
La bombe à fourche suivante a été présentée comme une œuvre d'art en 2002 56 ;
son origine exacte est inconnue, mais elle existait sur Usenet avant 2002.
La bombe est exécutée en collant les 13 caractères suivants dans un
Shell UNIX tel que bash ou zsh. Il fonctionne en définissant
une fonction appelée ':', qui s'appelle deux fois, une
fois au premier plan et une fois en arrière-plan.
Cependant, le dernier élément n'est pas tout à fait clair pour moi. Je vois la définition de la fonction :
:(){ ... }
Mais que se passe-t-il d'autre ? Faites également d'autres shells tels que ksh , csh , et tcsh aussi subir le même sort de pouvoir construire quelque chose de similaire ?
Réponse acceptée :
Cette bombe à fourche me rappelle toujours ce qu'un professeur de programmation d'IA a dit lors de l'une des premières leçons auxquelles j'ai assisté "Pour comprendre la récursivité, vous devez d'abord comprendre la récursivité".
À la base, cette bombe est une fonction récursive. Essentiellement, vous créez une fonction, qui s'appelle, qui s'appelle, qui s'appelle…. jusqu'à ce que les ressources système soient consommées. Dans ce cas précis, la récursivité est amplifiée par l'utilisation de la canalisation de la fonction vers elle-même ET de sa mise en arrière-plan.
J'ai vu cette réponse sur StackOverflow, et je pense que l'exemple donné ici l'illustre le mieux, simplement parce qu'il est plus facile de voir ce qu'il fait en un coup d'œil (volé du lien ci-dessus…)
☃(){ ☃|☃& };☃
Définir la fonction bogue ☃() { ... } , dont le corps s'appelle lui-même (la fonction de bogue), redirigeant la sortie vers lui-même (la fonction de bogue) ☃|☃ , et fond le résultat & . Ensuite, une fois la fonction définie, appelez la fonction de bogue, ; ☃ .
Je note qu'au moins sur mon Arch VM, la nécessité d'arrière-plan du processus n'est pas une exigence pour avoir le même résultat final, pour consommer tout l'espace de processus disponible et rendre l'hôte b0rked. En fait, maintenant, j'ai dit qu'il semble parfois mettre fin au processus de fuite et après un écran complet de -bash: fork: Resource temporarily unavailable il s'arrêtera avec un Terminated (et journalctl affiche le vidage du noyau bash).
Pour répondre à votre question sur csh/tcsh, aucun de ces shells ne prend en charge les fonctions, vous ne pouvez utiliser qu'un alias. Donc, pour ces shells, vous devez écrire un script shell qui s'appelle de manière récursive.
zsh semble subir le même sort (avec le même code), n'effectue pas de core dump et fait en sorte qu'Arch donne Out of memory: Kill process 216 (zsh) score 0 or sacrifice child. , mais il continue toujours à bifurquer. Au bout d'un moment, il indique alors Killed process 162 (systemd-logind) ... (et continue toujours d'avoir un forking zsh).
Arch ne semble pas avoir de pacman version de ksh, j'ai donc dû l'essayer sur debian à la place. objets ksh à : comme nom de fonction, mais en utilisant quelque chose - dites b() semble plutôt avoir le résultat souhaité.