Je rencontre le même problème et au début, je pensais comme ci-dessus que gdb ignore peut-être la capacité de l'exécutable pour des raisons de sécurité. Cependant, lire le code source et même utiliser eclipse pour déboguer gdb lui-même lorsqu'il débogue mon ext2fs-prog qui ouvre /dev/sda1 , je me rends compte que :
- gdb n'est pas spécial comme n'importe quel autre programme. (Tout comme dans la matrice, même les agents eux-mêmes obéissent à la même loi physique, gravité, etc., sauf qu'ils sont tous des gardiens.)
- gdb n'est pas le processus parent de l'exécutable débogué, c'est plutôt le grand-père.
- Le véritable processus parent de l'exécutable débogué est "shell", c'est-à-dire
/bin/bashdans mon cas.
Donc, la solution est très simple, à part ajouter cap_net_admin,cap_net_raw+eip à gdb, vous devez également l'appliquer à votre shell. c'est-à-dire setcap cap_net_admin,cap_net_raw+eip /bin/bash
La raison pour laquelle vous devez également faire cela pour gdb est que gdb est le processus parent de /bin/bash avant de créer un processus débogué.
La véritable ligne de commande exécutable à l'intérieur de gdb ressemble à ceci :
/bin/bash exec /my/executable/program/path
Et c'est le paramètre de vfork à l'intérieur de gdb.
Pour ceux qui ont le même problème, vous pouvez contourner celui-ci en exécutant gdb avec sudo.
Il y a quelque temps, j'ai rencontré le même problème. Je suppose que l'exécution du programme débogué avec les fonctionnalités supplémentaires est un problème de sécurité.
Votre programme a plus de privilèges que l'utilisateur qui l'exécute. Avec un débogueur, un utilisateur peut manipuler l'exécution du programme. Ainsi, si le programme s'exécute sous le débogueur avec les privilèges supplémentaires, l'utilisateur peut utiliser ces privilèges à d'autres fins que celles pour lesquelles le programme a prévu de les utiliser. Ce serait une grave faille de sécurité, car l'utilisateur n'a pas les privilèges en premier lieu.