web-dev-qa-db-fra.com

Pourquoi strace / gdb ne s’attache-t-il pas à un processus alors que je suis root?

  • Je me suis connecté en tant que root mais strace me donne ceci:

    root @ kyznecov-System:/home/kyznecov # ps -e | grep 111 
 3807 pts/2 00:00:00 111 
 3810 pts/2 00:00:00 111 
 root @ kyznecov-System:/home/kyznecov # strace - p 3810 
 
 attach: ptrace (PTRACE_ATTACH, ...): opération non autorisée 
 Impossible de lier le processus. Si votre uid correspond à celui du processus cible 
, Vérifiez le paramétrage de/proc/sys/kernel/yama/ptrace_scope ou essayez à nouveau 
 en tant qu'utilisateur root. Pour plus de détails, voir /etc/sysctl.d/10-ptrace.conf
root@kyznecov-System:/home/kyznecov[.____._rev.____.]root@kyznecov-System:/home/kyznecov # cat /proc/sys/kernel/yama/ptrace_scope
0

  • J'ai ensuite essayé d'utiliser gdb pour déboguer un programme multiprocessus dans Eclipse CDT avec forking et cela m'a donné le même résultat/erreur:

    enter image description here

Des idées?

11.1012.04kernelprogrammingdebugging
26
andreykyz

Une raison pour obtenir l'erreur:

attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

cela est dû au fait que le processus a déjà été associé à gdb, strace ou similaire. Pour vérifier si c'est le cas, lancez:

grep TracerPid /proc/$THE_PID/status

S'il est différent de zéro, il s'agit du pid d'un programme existant qui exécute déjà une trace sur ce processus.

25
Nathan Kidd

Comme izx a commenté, cela ne devrait se produire qu’à cause d’un bogue du noyau. Donc quiconque peut actuellement produire ce problème - y compris et surtout l'affiche originale de cette question - serait bien avisé de signalez-le comme un bug en lisant cette page soigneusement et soigneusement, puis exécutez ubuntu-bug linux sur la machine affectée . Cela devrait être rapporté avec linux dans Ubuntu, et pas contre un noyau principal (en amont), à moins que vous ne puissiez le produire sur un noyau principal (vous devez avoir yama chargé). .

Le comportement attendu dans toutes les versions d'Ubuntu commençant par Ubuntu 10.10 est que le processus A ne peut pas suivre un processus en cours d'exécution B sauf si B est un enfant direct de A (ou A s'exécute en tant que root). Il s'agit d'une amélioration de la sécurité, qui fait en sorte qu'un processus compromis par un attaquant ne peut pas utiliser les fonctionnalités de débogage fournies par le noyau pour découvrir des informations provenant d'autres processus. Ceci est expliqué dans la section ptrace scope de la page de wiki de la communauté Security Features .

Ce comportement restrictif est le comportement par défaut, mais il peut être modifié pour permettre à un processus A de suivre tout processus en cours d'exécution B exécuté avec le même ID utilisateur que le processus A propre. Autrement dit, vous pouvez configurer votre système pour autoriser l’un quelconque de vos processus à se déboguer. Cela simplifie la liaison des débogueurs aux processus déjà en cours d'exécution.

Le paramètre pour cela est exposé dans le /proc/sys/kernel/yama/ptrace_scopesysctl . 1 indique le comportement le plus restrictif et 0 le comportement le moins restrictif. Le réglage peut être lu avec:

cat /proc/sys/kernel/yama/ptrace_scope

Le comportement moins restrictif (autre que celui par défaut) peut être défini avec:

echo 0 | Sudo tee /proc/sys/kernel/yama/ptrace_scope

Et le comportement plus restrictif (par défaut) peut être défini (ou réduit) avec:

echo 1 | Sudo tee /proc/sys/kernel/yama/ptrace_scope

Non seulement l'affiche originale de cette question n'a pas pu associer une instance strace à un processus en cours d'exécution avec ptrace-scope défini sur 0, mais l'affiche originale ne pouvait toujours pas le faire lors de l'exécution de strace en tant que root. Il est difficile de voir comment cela pourrait être autre chose qu'un bogue - je recommande fortement de le signaler comme tel.

Au début, j’avais pensé que j’étais capable de reproduire le problème où un paramètre ptrace_scope de 0 est ignoré et traité comme s’il s’agissait de 1. Mais je ne crois plus que ce soit le cas, car j’ai refait toutes les mêmes choses et je ne peux pas reproduire le problème. J'ai testé cela sur:

  • La machine physique Lubuntu Precise AMD64 que j’utilise quotidiennement comme boîtier principal.
  • Une machine virtuelle VirtualBox exécutant un CD live Lubuntu Precise i386 (12.04).
  • Une machine virtuelle VirtualBox identique exécutant Quotidien-Live (20120608) Quantal i386 (Ubuntu + 1).

Le comportement attendu se produit sur les trois machines et je ne peux pas reproduire la condition sur laquelle l’affiche originale de cette question demande. Voici un texte du terminal (du système Precise Live):

lubuntu@lubuntu:~$ nano&
[1] 3492
lubuntu@lubuntu:~$ strace -p 3492
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf

[1]+  Stopped                 nano
lubuntu@lubuntu:~$ cat /proc/sys/kernel/yama/ptrace_scope
1
lubuntu@lubuntu:~$ echo 0 | Sudo tee /proc/sys/kernel/yama/ptrace_scope
0
lubuntu@lubuntu:~$ strace -p 3492
Process 3492 attached - interrupt to quit
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
ioctl(1, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = ? ERESTARTSYS (To be restarted)
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---
ioctl(1, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = ? ERESTARTSYS (To be restarted)
--- SIGTTOU (Stopped (tty output)) @ 0 (0) ---

strace a continué à produire des messages jusqu'à ce que je le suspende, comme prévu.

Je conclus en recommandant à nouveau de signaler ceci comme un bug. Une recherche extrêmement inclusive sur https://bugs.launchpad.net (qui inclut tous les bogues signalés par Ubuntu) pour le texte ptrace_scope produit juste une poignée de résultats, dans lesquels aucun ne correspond clairement à un rapport pour ce bug . Signaler le bogue aiderait les autres, pourrait conduire à des solutions de contournement ou à une solution, et constitue probablement le seul moyen significatif de continuer à travailler sur ce problème (en supposant que le problème persiste).

18
Eliah Kagan