Perché strace / gdb non si attaccherà a un processo anche se sono root?

• Ho effettuato l'accesso come root ma stracemi dà questo:

  root @ kyznecov-System: / home / kyznecov # ps -e | grep 111
   3807 punti / 2 00:00:00 111
   3810 punti / 2 00:00:00 111
  root @ kyznecov-System: / home / kyznecov # strace -p 3810
  
  attach: ptrace (PTRACE_ATTACH, ...): operazione non consentita
  Impossibile collegarsi al processo. Se il tuo uid corrisponde a quello del target
  processo, controlla l'impostazione di / proc / sys / kernel / yama / ptrace_scope o prova
  di nuovo come utente root. Per maggiori dettagli, consultare /etc/sysctl.d/10-ptrace.conf
  root @ kyznecov-System: / home / kyznecov
  
  root @ kyznecov-System: / home / kyznecov # cat / proc / sys / kernel / yama / ptrace_scope
  0

• Ho quindi provato a utilizzare gdbper eseguire il debug di un programma multiprocesso in Eclipse CDT con il fork e mi ha dato lo stesso risultato / errore:

  

Qualche idea?

Un motivo per ottenere l'errore:

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

è perché il processo è già stato attaccato con gdb, straceo simili. Per verificare se questo è il caso, eseguire:

grep TracerPid /proc/$THE_PID/status

Se è diverso da zero, questo è il pid di un programma esistente che sta già eseguendo una traccia su quel processo.

Come ha commentato izx , questo dovrebbe essere possibile solo a causa di un bug del kernel. Pertanto, chiunque sia attualmente in grado di produrre questo problema, incluso e in particolare il poster originale di questa domanda, sarebbe ben consigliato di segnalarlo come un bug leggendo quella pagina in modo accurato e accurato e quindi eseguendolo ubuntu-bug linuxsul computer interessato . Questo dovrebbe essere segnalato contro linuxUbuntu, e non contro un kernel mainline (upstream), a meno che tu non possa produrlo su un kernel mainline (dovresti averlo yamacaricato).

Il comportamento previsto in ogni versione di Ubuntu che inizia con Ubuntu 10.10 è che il processo A non può tracciare un processo in esecuzione B a meno che B non sia un figlio diretto di A (o A gira come root). Questo è un miglioramento della sicurezza, che rende tale che un processo che è stato compromesso da un utente malintenzionato non può utilizzare le funzionalità di debug fornite dal kernel per scoprire informazioni da altri processi. Questo è spiegato nella sezione dell'ambito ptrace della pagina wiki della comunità Funzionalità di sicurezza .

Questo comportamento restrittivo è l'impostazione predefinita, ma può essere modificato per consentire a un processo A di tracciare qualsiasi processo in esecuzione B eseguito con lo stesso ID utente del processo A. Cioè, è possibile configurare il sistema in modo da consentire il debug reciproco di tutti i processi. Ciò semplifica il collegamento dei debugger ai processi già in esecuzione.

L'impostazione per questo è esposta da /proc/sys/kernel/yama/ptrace_scope sysctl . 1indica il comportamento più restrittivo e 0il comportamento meno restrittivo. L'impostazione può essere letta con:

cat /proc/sys/kernel/yama/ptrace_scope

Il comportamento meno restrittivo (non predefinito) può essere impostato con:

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

E il comportamento più restrittivo (predefinito) può essere impostato (o ripristinato) con:

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

Non solo il poster originale di questa domanda non è stato in grado di allegare straceun'istanza a un processo attualmente in esecuzione con ptrace-scopeset su 0, ma il poster originale non è stato ancora in grado di farlo durante l'esecuzione stracecome root. È difficile capire come questo possa essere tutt'altro che un bug - consiglio vivamente di segnalarlo come tale.

All'inizio, avevo pensato di essere in grado di riprodurre il problema in cui ptrace_scopeun'impostazione di 0viene ignorata e trattata come se fosse 1. Ma non credo più che sia così, poiché ho ripetuto tutte le stesse cose e non riesco a riprodurre il problema. Ho provato questo su:

• La macchina fisica Lubuntu Precise amd64 che uso quotidianamente come scatola principale.
• Una macchina virtuale VirtualBox che esegue un CD live Lubuntu Precise i386 (12.04).
• Una macchina virtuale VirtualBox identica che esegue un Quantal i386 (Ubuntu + 1) daily-live (20120608).

Su tutte e tre le macchine, si verifica il comportamento previsto e non riesco a riprodurre la condizione richiesta dal poster originale di questa domanda. Ecco un po 'di testo dal Terminale (dal sistema live Precise):

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 ha continuato a produrre messaggi fino a quando non l'ho sospeso, come previsto.

Concludo raccomandando di nuovo di segnalarlo come un bug. Una ricerca al massimo inclusiva su https://bugs.launchpad.net (che include tutti i bug di Ubuntu segnalati) per il testo ptrace_scopeproduce solo una manciata di risultati, in cui chiaramente non ci sono segnalazioni per questo errore . Segnalare il bug aiuterebbe gli altri, potrebbe portare a soluzioni alternative o una correzione ed è probabilmente l'unico modo significativo per procedere in avanti su questo problema (supponendo che il problema si stia ancora verificando).