Mi imbatto nello stesso problema e all'inizio ho pensato come sopra che forse gdb sta ignorando la capacità dell'eseguibile per motivi di sicurezza. Tuttavia, la lettura del codice sorgente e persino l'utilizzo di Eclipse per il debug di gdb stesso quando esegue il debug del mio ext2fs-prog che apre /dev/sda1 , mi rendo conto che:
- gdb non è speciale come qualsiasi altro programma. (Proprio come è nella matrice, anche gli stessi agenti obbediscono alla stessa legge fisica, gravità ecc., tranne per il fatto che sono tutti guardiani della porta.)
- gdb non è il processo genitore dell'eseguibile sottoposto a debug, invece è il nonno.
- Il vero processo padre dell'eseguibile sottoposto a debug è "shell", cioè
/bin/bashnel mio caso.
Quindi, la soluzione è molto semplice, a parte l'aggiunta di cap_net_admin,cap_net_raw+eip a gdb, devi applicarlo anche alla tua shell. cioè setcap cap_net_admin,cap_net_raw+eip /bin/bash
Il motivo per cui devi farlo anche con gdb è perché gdb è il processo padre di /bin/bash prima di creare il processo di debug.
La vera riga di comando eseguibile all'interno di gdb è la seguente:
/bin/bash exec /my/executable/program/path
E questo è il parametro per vfork all'interno di gdb.
Per coloro che hanno lo stesso problema, puoi aggirare questo eseguendo gdb con sudo.
Tempo fa ho riscontrato lo stesso problema. La mia ipotesi è che l'esecuzione del programma sottoposto a debug con le funzionalità aggiuntive sia un problema di sicurezza.
Il tuo programma ha più privilegi dell'utente che lo esegue. Con un debugger un utente può manipolare l'esecuzione del programma. Quindi, se il programma viene eseguito nel debugger con i privilegi extra, l'utente potrebbe utilizzare questi privilegi per scopi diversi da quelli per cui il programma intendeva utilizzarli. Questo sarebbe un grave buco di sicurezza, perché l'utente non ha i privilegi in primo luogo.