gdb parece ignorar las capacidades ejecutables

Question

Estoy depurando un programa que hace uso de libnetfilter_queue. La documentación indica que una aplicación de manejo de colas en el espacio de usuario necesita la función CAP_NET_ADMIN para funcionar. He hecho esto con la utilidad setcap de la siguiente manera:

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

He comprobado que las capacidades se aplican correctamente como) funciona el programa y b) getcap devuelve el siguiente resultado:

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

Sin embargo , cuando intento depurar este programa utilizando gdb (por ejemplo, $ gdb ./a.out) desde la línea de comandos, falla debido a que no se han establecido los permisos correctos. La funcionalidad de depuración de gdb funciona perfectamente de lo contrario y se depura como de costumbre.

Incluso he intentado aplicar estas capacidades al gdb binario en sí mismo en vano. Hice esto como parecía (como lo demuestra la manpages que el "i" bandera podría permitido depurando un programa para heredar la capacidad del depurador.

¿Hay algo trivial que me falta o puedo no realmente puede hacer?

Answer 1

hace un tiempo se ha ejecutado en el mismo problema. Mi conjetura es que la ejecución del programa depurado con las capacidades adicionales es un problema de seguridad.

su programa tiene más privilegios que el usuario que lo ejecuta. con un depurador un usuario puede manipular la ejecución del programa. Por lo tanto, si el programa se ejecuta bajo el depurador con los privilegios adicionales, entonces el usuario podría usar estos privilegios. ileges para otros fines que para los cuales el programa pretendía usarlos. Esto sería un agujero de seguridad serio, porque el usuario no tiene los privilegios en primer lugar.

Answer 2

Para aquellos que tienen el mismo problema, puede omitir este ejecutando gdb con sudo.

Answer 3

Me encuentro con el mismo problema y al principio pensé lo mismo que arriba que tal vez gdb está ignorando la capacidad del ejecutable debido a razones de seguridad. Sin embargo, la lectura de código fuente e incluso el uso de Eclipse en sí GDB depuración cuando se está depurando mi ext2fs-prog que se abre /dev/sda1, comprendo que:

1. GDB hay especial como cualquier otro programa. (Al igual que en la matriz, incluso los propios agentes obedecen la misma ley física, la gravedad, etc., excepto que son todos porteros).
2. gdb no es el proceso principal del archivo ejecutable depurado, en cambio es grandioso padre.
3. El verdadero proceso principal del ejecutable depurado es "shell", es decir, /bin/bash en mi caso.

Por lo tanto, la solución es muy simple, además de agregar cap_net_admin,cap_net_raw+eip a gdb, también debe aplicar esto a su shell. es decir, setcap cap_net_admin,cap_net_raw+eip /bin/bash

La razón por la que también tiene que hacer esto con gdb es porque gdb es el proceso principal de /bin/bash antes de crear el proceso depurado.

La verdadera línea de comandos ejecutable dentro de gdb es como siguiente:

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

Y este es el parámetro a vfork dentro de gdb.

Answer 4

Para aquellos que ejecutan GDB a través de un IDE, sudo-ing GDB (como en la respuesta de @ Stéphane J.) puede no ser posible. En este caso, puede ejecutar:

sudo gdbserver localhost:12345 /path/to/application 

y luego coloque ejemplo GDB de su IDE para que gdbserver (local).

En el caso de Eclipse CDT, esto significa hacer una nueva configuración de depuración de 'C/C++ Remote Application', luego en la pestaña Depurador> Conexión, ingresar TCP/localhost/12345 (o cualquier puerto que elija anteriormente). Esto le permite depurar dentro de Eclipse, mientras que su aplicación tiene acceso privilegiado.