On Wed, 19 Jan 2005 00:18:57 +0000, Nicolas George wrote:
Jérémy JUST wrote in message :
Ah? Quel hack peut être utilisé?
Originalement, il me semble, cd était un binaire externe qui allait tripatouiller dans les structures de données du noyau pour changer le répertoire courant de son processus père. Une horreur. Mais c'était l'époque où mkdir allait taper directement dans le filesystem et autres joyeusetés du même genre.
Plus récemment, j'ai écrit pour faire joujou un programme externe cd qui utilise ptrace (donc non-portable, exclusivement Linux/x86) pour forcer son père à changer de répertoire courant.
Deux remarques: - ptrace est fait pour tracer un processus fils. S'en servir pour accéder au père est un contresens. - ptrace est disponible sur toutes les architectures. Donc, en l'utilisant judicieusement, on peut faire des programmes tout à fait portables et même qui marchent sur d'autres Unix que Linux.
À vrai dire, je ne comprends pas l'intérêt du programme « cd »
A l'origine, à pouvoir faire: execve("/bin/cd", args, env); dans un programme, rien de plus.
[...]
On Wed, 19 Jan 2005 00:18:57 +0000, Nicolas George wrote:
Jérémy JUST wrote in message
<20050119004242.6b9ab856@norbert.inapg.inra.fr>:
Ah? Quel hack peut être utilisé?
Originalement, il me semble, cd était un binaire externe qui allait
tripatouiller dans les structures de données du noyau pour changer le
répertoire courant de son processus père. Une horreur. Mais c'était l'époque
où mkdir allait taper directement dans le filesystem et autres joyeusetés du
même genre.
Plus récemment, j'ai écrit pour faire joujou un programme externe cd qui
utilise ptrace (donc non-portable, exclusivement Linux/x86) pour forcer son
père à changer de répertoire courant.
Deux remarques:
- ptrace est fait pour tracer un processus fils. S'en servir pour accéder
au père est un contresens.
- ptrace est disponible sur toutes les architectures. Donc, en l'utilisant
judicieusement, on peut faire des programmes tout à fait portables et
même qui marchent sur d'autres Unix que Linux.
À vrai dire, je ne comprends pas l'intérêt du programme « cd »
A l'origine, à pouvoir faire:
execve("/bin/cd", args, env);
dans un programme, rien de plus.
On Wed, 19 Jan 2005 00:18:57 +0000, Nicolas George wrote:
Jérémy JUST wrote in message :
Ah? Quel hack peut être utilisé?
Originalement, il me semble, cd était un binaire externe qui allait tripatouiller dans les structures de données du noyau pour changer le répertoire courant de son processus père. Une horreur. Mais c'était l'époque où mkdir allait taper directement dans le filesystem et autres joyeusetés du même genre.
Plus récemment, j'ai écrit pour faire joujou un programme externe cd qui utilise ptrace (donc non-portable, exclusivement Linux/x86) pour forcer son père à changer de répertoire courant.
Deux remarques: - ptrace est fait pour tracer un processus fils. S'en servir pour accéder au père est un contresens. - ptrace est disponible sur toutes les architectures. Donc, en l'utilisant judicieusement, on peut faire des programmes tout à fait portables et même qui marchent sur d'autres Unix que Linux.
À vrai dire, je ne comprends pas l'intérêt du programme « cd »
A l'origine, à pouvoir faire: execve("/bin/cd", args, env); dans un programme, rien de plus.
[...]
Nicolas George
l'indien wrote in message :
- ptrace est fait pour tracer un processus fils. S'en servir pour accéder au père est un contresens.
ptrace est fait pour tracer n'importe quel processus. Le traçage d'un processus fils est à certains point de vue plus facile, et surtout plus fiable au moment de l'attachement, ce qui justifie un traitement de faveur dans ptrace, mais génériquement, n'importe quel processus peut être tracé, y compris le processus père.
- ptrace est disponible sur toutes les architectures. Donc, en l'utilisant judicieusement, on peut faire des programmes tout à fait portables et même qui marchent sur d'autres Unix que Linux.
Le seul moyen fiable de faire ce que j'ai fait est de provoquer un appel système, or l'ABI du noyau dépend complètement de l'architecture : il faut mettre des arguments dans des registres, etc.
l'indien wrote in message <pan.2005.01.19.11.02.18.211342@magic.fr>:
- ptrace est fait pour tracer un processus fils. S'en servir pour accéder
au père est un contresens.
ptrace est fait pour tracer n'importe quel processus. Le traçage d'un
processus fils est à certains point de vue plus facile, et surtout plus
fiable au moment de l'attachement, ce qui justifie un traitement de faveur
dans ptrace, mais génériquement, n'importe quel processus peut être tracé, y
compris le processus père.
- ptrace est disponible sur toutes les architectures. Donc, en l'utilisant
judicieusement, on peut faire des programmes tout à fait portables et
même qui marchent sur d'autres Unix que Linux.
Le seul moyen fiable de faire ce que j'ai fait est de provoquer un appel
système, or l'ABI du noyau dépend complètement de l'architecture : il faut
mettre des arguments dans des registres, etc.
- ptrace est fait pour tracer un processus fils. S'en servir pour accéder au père est un contresens.
ptrace est fait pour tracer n'importe quel processus. Le traçage d'un processus fils est à certains point de vue plus facile, et surtout plus fiable au moment de l'attachement, ce qui justifie un traitement de faveur dans ptrace, mais génériquement, n'importe quel processus peut être tracé, y compris le processus père.
- ptrace est disponible sur toutes les architectures. Donc, en l'utilisant judicieusement, on peut faire des programmes tout à fait portables et même qui marchent sur d'autres Unix que Linux.
Le seul moyen fiable de faire ce que j'ai fait est de provoquer un appel système, or l'ABI du noyau dépend complètement de l'architecture : il faut mettre des arguments dans des registres, etc.
