Pourquoi strace / gdb ne s'attache-t-il pas à un processus même si je suis root?

• Je me suis connecté en tant que root mais straceme 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 joindre au processus. Si votre UID correspond à l'UID de la cible
  , vérifiez le paramètre 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
  
  root @ kyznecov-System: / home / kyznecov # cat / proc / sys / kernel / yama / ptrace_scope
  0

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

  

Des idées?

Une raison pour obtenir l'erreur:

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

est parce que le processus a déjà été attaché à avec gdb, straceou similaire. Pour vérifier si c'est le cas, exécutez:

grep TracerPid /proc/$THE_PID/status

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

Comme l' a commenté izx , cela ne devrait pouvoir se produire qu'en raison d'un bug du noyau. Donc, toute personne qui peut actuellement produire ce problème - y compris et en particulier l'affiche originale de cette question - serait bien avisée de le signaler comme un bug en lisant cette page attentivement et attentivement, puis en exécutant ubuntu-bug linuxsur la machine affectée . Cela devrait être signalé linuxdans Ubuntu, et non contre un noyau principal (en amont), à moins que vous ne puissiez le produire sur un noyau principal (vous auriez dû le yamacharger).

Le comportement attendu dans chaque version d'Ubuntu commençant par Ubuntu 10.10 est que le processus A ne peut pas tracer un processus en cours d'exécution B à moins que B soit 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 qui a été compromis par un attaquant ne puisse 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 étendue ptrace de la page wiki de la communauté des fonctionnalités de sécurité .

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

Le paramètre pour cela est exposé par le /proc/sys/kernel/yama/ptrace_scope sysctl . 1désigne le comportement le plus restrictif et 0le comportement le moins restrictif. Le réglage peut être lu avec:

cat /proc/sys/kernel/yama/ptrace_scope

Le comportement moins restrictif (non 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étrogradé) avec:

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

Non seulement l'affiche originale de cette question n'a pas pu joindre une straceinstance à un processus en cours d'exécution avec la valeur ptrace-scopeset to 0, mais l'affiche originale n'a toujours pas pu le faire lors de l'exécution en stracetant que root. Il est difficile de voir comment cela pourrait être autre chose qu'un bug - je recommande fortement de le signaler comme tel.

Au début, j'avais pensé que je pouvais reproduire le problème lorsqu'un ptrace_scopeparamètre de 0est ignoré et traité comme s'il l'était 1. Mais je ne crois plus que ce soit le cas, car j'ai encore fait la même chose, 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îte principale.
• Une machine virtuelle VirtualBox exécutant un CD live Lubuntu Precise i386 (12.04).
• Une machine virtuelle VirtualBox identique exécutant quotidiennement un Quantal i386 (Ubuntu + 1) (20120608).

Sur les trois machines, le comportement attendu se produit et je ne peux pas reproduire la condition posée par l'affiche originale de cette question. Voici un texte du terminal (du système live précis):

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 continué à produire des messages jusqu'à ce que je le suspende, comme prévu.

Je termine en recommandant à nouveau de signaler cela comme un bug. Une recherche au maximum inclusive sur https://bugs.launchpad.net (qui inclut tous les bogues Ubuntu signalés) pour le texte ptrace_scopeproduit juste une poignée de résultats, dans lesquels clairement aucun rapport n'est pour ce bogue . Signaler le bogue aiderait les autres, pourrait conduire à des solutions de contournement ou à un correctif, et est probablement le seul moyen significatif de continuer à travailler sur ce problème (en supposant que le problème persiste).