我正在debugging一个使用libnetfilter_queue的程序。 该文档指出，用户空间队列处理应用程序需要CAP_NET_ADMINfunction才能运行。 我已经完成了这个使用setcap实用程序，如下所示：
$ sudo setcap cap_net_raw,cap_net_admin=eip ./a.out
我已经validation，能力正确应用作为a）程序工作和b） getcap返回以下输出：
$ getcap ./a.out ./a.out = cap_net_admin,cap_net_raw+eip
但是，当我尝试$ gdb ./a.out使用gdb （例如$ gdb ./a.out ）来debugging这个程序时，由于没有设置正确的权限而失败。 gdb的debuggingfunction完美工作，并按照正常进行debugging。
我甚至试图将这些function应用到gdb二进制文件本身没有用。 我这样做是因为它看起来（正如manpages所logging的那样，“ i ”标志可能允许恶人inheritancedebugging器的能力。
有没有什么微不足道的东西我错过了，或者这真的不能做？
前段时间我遇到了同样的问题。 我的猜测是运行带有附加功能的调试程序是一个安全问题。
你的程序比运行它的用户拥有更多的权限。 使用调试器，用户可以操作程序的执行。 因此，如果程序在调试器下以额外权限运行，那么用户可以将这些权限用于其他目的，而不是程序打算使用它们。 这将是一个严重的安全漏洞，因为用户首先没有权限。
我遇到了同样的问题，一开始我以为和上面一样，也许gdb由于安全原因忽略了可执行文件的能力。 然而，在调试我的ext2fs-prog（打开/dev/sda1时，阅读源代码甚至使用eclipse调试gdb本身，我意识到：
/bin/bash 。 所以，解决方法非常简单，除了将cap_net_admin,cap_net_raw+eip添加到gdb之外，还可以将其应用到shell。 即setcap cap_net_admin,cap_net_raw+eip /bin/bash
你还必须这样做到gdb的原因是因为在创建调试过程之前，gdb是/bin/bash父进程。
gdb里的真正可执行的命令行如下所示：
/bin/bash exec /my/executable/program/path
这是gdb中的vfork参数。
对于那些有同样问题的人，可以通过sudo执行gdb来绕过这个问题。