gdb似乎忽略了可执行功能

Question

我正在调试一个使用的程序libnetfilter_queue.该文档指出用户空间队列处理应用程序需要CAP_NET_ADMIN能够运行.我使用该setcap实用程序完成了以下操作:

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

我已经验证了这些功能是否正确应用为a)程序正常工作,b)getcap返回以下输出:

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

但是,当我尝试使用gdb(例如$ gdb ./a.out)命令行调试此程序时,由于没有设置正确的权限,它会失败.调试功能gdb完全正常工作,并按照正常情况进行调试.

我甚至试图将这些功能应用于gdb二进制本身无济于事.我这样做了(正如manpages所记载的那样," i"标志可能允许debugee从调试器继承该功能.

有什么微不足道的我遗失或者这真的不能做到吗？

Answer 1

我遇到了同样的问题,一开始我就像上面一样认为,由于安全原因,gdb可能会忽略可执行文件的功能.但是,在调试我的ext2fs-prog打开时,阅读源代码,甚至使用eclipse调试gdb本身/dev/sda1,我意识到:

因此,解决方案非常简单,除了添加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的参数.

Answer 2

我使用了 @NickHuang 的解决方案，直到其中一个系统更新破坏了 systemd 服务（bash 上的功能太多，systemd 无法启动它或类似的功能）。改为单独保留 bash，而是将命令传递给 gdb 以直接调用可执行文件。命令是

set startup-with-shell off

Answer 3

不久前我也遇到了同样的问题。我的猜测是，运行具有附加功能的调试程序是一个安全问题。

您的程序比运行它的用户拥有更多的权限。使用调试器，用户可以操纵程序的执行。因此，如果程序在具有额外权限的调试器下运行，那么用户可以将这些权限用于程序打算使用它们之外的其他目的。这将是一个严重的安全漏洞，因为用户一开始就没有权限。