Me encontré 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, leer el código fuente e incluso usar eclipse depurando gdb cuando está depurando mi ext2fs-prog que abre /dev/sda1 , me doy cuenta de que:
- gdb no es 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 todos son porteros).
- gdb no es el proceso principal del ejecutable depurado, sino que es el abuelo.
- El verdadero proceso principal del ejecutable depurado es "shell", es decir,
/bin/bashen mi caso.
Entonces, la solución es muy simple, además de agregar cap_net_admin,cap_net_raw+eip a gdb, también ha aplicado 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 un proceso padre de /bin/bash antes de crear un proceso depurado.
La verdadera línea de comando ejecutable dentro de gdb es como la siguiente:
/bin/bash exec /my/executable/program/path
Y este es un parámetro para vfork dentro de gdb.
Para aquellos que tienen el mismo problema, pueden omitir este ejecutando gdb con sudo.
Hace un tiempo me encontré con el mismo problema. Supongo que ejecutar el programa depurado con 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. Entonces, si el programa se ejecuta bajo el depurador con los privilegios adicionales, entonces el usuario podría usar estos privilegios para fines distintos a los que el programa pretendía usar. Esto sería un grave agujero de seguridad, porque el usuario no tiene los privilegios en primer lugar.