gdb sembra ignorare le funzionalità eseguibili

Question

Io sono il debug di un programma che fa uso di libnetfilter_queue. La documentazione che un'applicazione userspace coda di gestione ha bisogno della capacità CAP_NET_ADMIN alla funzione. Ho fatto questo utilizzando l'utilità setcap come segue:

$ sudo setcap cap_net_raw,cap_net_admin=eip ./a.out

Ho verificato che le funzionalità siano correttamente applicate come) funziona il programma e b) restituisce getcap il seguente output:

$ getcap ./a.out
./a.out = cap_net_admin,cap_net_raw+eip

Tuttavia, quando si tenta di eseguire il debug di questo programma utilizzando gdb (per esempio $ gdb ./a.out) dalla riga di comando, non riesce a causa di non avere le autorizzazioni corrette impostate. La funzionalità di debug di gdb funziona perfettamente altrimenti e il debug come al solito.

Ho anche cercato di applicare queste capacità al gdb binario stesso senza alcun risultato. Ho fatto questo come sembrava (come documentato dalla pagine man che la bandiera "i" potrebbe permesso al debugee di ereditare la capacità dal debugger.

C'è qualcosa di banale che mi manca o posso non davvero fare?

Answer 1

Qualche tempo fa ho incontrato lo stesso problema. La mia ipotesi è che l'esecuzione del programma di debug con le funzionalità aggiuntive è un problema di sicurezza.

Il programma ha più privilegi rispetto all'utente che lo gestisce. Con un debugger un utente può manipolare l'esecuzione del programma. Quindi, se il programma viene eseguito nel debugger con i privilegi extra quindi l'utente potrebbe utilizzare questi privilegi per altri scopi diversi da quelli per i quali il programma destinato a usarli. Questo sarebbe un grave buco di sicurezza, perché l'utente non dispone dei privilegi, in primo luogo.

Answer 2

mi imbatto in stesso problema e all'inizio ho pensato la stessa di cui sopra che forse gdb sta ignorando la capacità del file eseguibile a causa di motivi di sicurezza. Tuttavia, la lettura del codice sorgente e anche utilizzando eclissi di debug gdb stesso quando è il debug mio ext2fs-prog che si apre /dev/sda1, mi rendo conto che:

1. gdb è speciale come qualsiasi altro programma. (Come è nella matrice, anche gli agenti stessi obbediscono alla stessa legge fisica, gravità ecc, eccetto che sono tutti portieri.)
2. gdb non è il processo padre di debug eseguibile, invece è nonno.
3. Il vero processo padre di eseguibile debug è "guscio", vale a dire /bin/bash nel mio caso.

Quindi, la soluzione è molto semplice, a parte l'aggiunta di cap_net_admin,cap_net_raw+eip a gdb, avete anche applicare questo alla vostra shell. cioè setcap cap_net_admin,cap_net_raw+eip /bin/bash

La ragione per cui si hanno anche per fare questo per gdb gdb è perché è processo padre di /bin/bash prima di creare processo di debug.

La vera linea di comando eseguibile all'interno gdb è come segue:

/bin/bash exec /my/executable/program/path

E questo è il parametro per vfork dentro gdb.

Answer 3

Per coloro che hanno lo stesso problema, è possibile ignorare questo uno eseguendo gdb con sudo.

Answer 4

Per quelli in esecuzione GDB tramite un IDE, sudo-ing GDB (come nel @ risposta di Stéphane J.) potrebbe non essere possibile. In questo caso, è possibile eseguire:

sudo gdbserver localhost:12345 /path/to/application

e quindi collegare esempio GDB del vostro IDE a quella (locale) gdbserver.

Nel caso di Eclipse CDT, Questo significa fare una nuova configurazione di debug 'C / C ++ Remote Application', poi sotto la> scheda Connessione Debugger, entrando TCP / localhost / 12345 (o qualsiasi altra cosa la porta si è scelto in precedenza). Ciò consente di eseguire il debug all'interno di Eclipse, mentre l'applicazione dispone di un accesso privilegiato.