为什么gdb需要root权限来调试用户程序？
我一直在使用gdb相当成功一段时间，但我最近升级了我的Ubuntu版本，现在看来我只能让gdb成功运行我的程序，如果我以root身份运行的话。也就是说，为什么gdb需要root权限来调试用户程序？
~ % gdb -q sleep -ex 'run 60'
Reading symbols from /bin/sleep...(no debugging symbols found)...done.
Starting program: /bin/sleep 60
tcsh: Permission denied.
During startup program exited with code 1.
(gdb)
失败，而
~ % sudo gdb -q sleep -ex 'run 60'
Reading symbols from /bin/sleep...(no debugging symbols found)...done.
Starting program: /bin/sleep 60
Running .tcshrc
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
^C
Program received signal SIGINT, Interrupt.
0x00007ffff7adada0 in __nanosleep_nocancel() at ../sysdeps/unix/syscall-template.S:82
82 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb)
作品。一个线索是，在第一种情况下，gdb启动不会运行我的.tcshrc文件，而在第二种情况下，它会运行。
看起来这是一个简单的权限问题，我必须一次性修复这个问题，因为在过去，我从不需要以root身份运行gdb。然而，经过大量的搜索，我无法找到我可能做了什么（如果我确实做了什么）。一个可能的修复 - 设置ptrace permissions - 似乎没有工作。
是否有某些事情需要完成，以允许gdb在没有root权限的情况下运行程序？我知道在OSX中，gdb必须进行编码。 Ubuntu/Linux有类似的东西吗？
我将登录shell更改为bash，并且gdb不再需要root权限进行调试。下面是最新的：
我.gdbinit文件：
(bash) ~ % more .gdbinit show environment SHELL file /bin/echo run 'running .gdbinit' (bash) ~ %
和运行gdb结果：
(bash) ~ % gdb -q -batch SHELL = /bin/bash running .gdbinit [Inferior 1 (process 3174) exited normally] (bash) ~ %
我还是不明白，为什么tcsh中没有工作，虽然和我很好奇知道。所以如果有人有可能的解释，请评论。
我应该补充一点，我重新安装了tcsh，并且没有运行.tcshrc文件（我把它移动了），权限被拒绝的问题仍然是一个谜。这对我的设置很有趣 - 我只是希望我能弄清楚tcsh试图运行的是什么，它没有权限运行（gdb是root）。 – Donna 2014-09-01 12:19:34
更新：我re =安装了tcsh（它没有改变任何东西），在.tcshrc中检查（再次）权限，重新启动和Voila，对于tcsh和gdb都是很好的。仍然不知道发生了什么。但是，我学到了：（1）gdb调用shell并且（2）SHELL变量不是通过从命令行调用'tcsh'或'bash'自动设置的（仅当shell作为登录shell启动时）。所以一切都不会丢失。 – Donna 2014-09-01 19:06:50
这里是调试gdb问题的一些想法。评论对于这样的事情是不可行的，所以我把它们放入了答案中。
尝试-n选项以确保没有加载init文件。
使用echo程序而不是sleep 60，使调试简单（在你的榜样的SIGINT事情可能是特定的睡眠程序
运行gdb -batch并把其余的为~/.gdbinit：
file /bin/echo
run
加set verbose on
别忘了清理~/.gdbinit做完
这不是一个完整的答案，但事情变得更加清晰。上面的提示非常有帮助。我创建了以下文件.gdbinit文件
show environment SHELL file /bin/echo run 'Goodbye'
并且结果很有趣。如果SHELL=/usr/tcsh，我得到一个权限错误，即
~ % setenv SHELL /bin/tcsh ~ % gdb -q -batch SHELL = /bin/tcsh tcsh: Permission denied. /home/calhoun/.gdbinit:12: Error in sourced command file: During startup program exited with code 1.
解封shell变量作品：
~ % unsetenv SHELL ~ % gdb -q -batch Environment variable "SHELL" not defined. Goodbye [Inferior 1 (process 6992) exited normally]
在这种情况下，run使用/bin/sh扩大参数列表。将SHELL设置为/bin/bash或/bin/dash将使用这些shell来扩展参数列表，例如，
~ % setenv SHELL /bin/bash ~ % gdb -q -batch SHELL = /bin/bash warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000 Goodbye [Inferior 1 (process 7280) exited normally]
奇怪的是，“没有装入节错误仅发生在shell变量明确设置，另一个谜。
为什么/bin/tcsh不起作用仍是莫名其妙。在我的情况下，/bin/tcsh的权限
~ % ls -lh /bin/tcsh lrwxrwxrwx 1 root root 13 Oct 14 2011 /bin/tcsh -> /usr/bin/tcsh ~ % ls -lh /usr/bin/tcsh -rwxr-xr-x 1 root root 382K Oct 14 2011 /usr/bin/tcsh
的问题也可能会是在我.tcshrc文件，导致该壳在这个非交互模式崩溃。
我猜想后者是真的：权限被拒绝的错误是tcsh试图执行的东西，而不是执行tcsh本身。应该很容易找到，但为什么要麻烦？ – user829755 2014-08-31 14:51:34
或者，tcsh正在尝试做一些gdb没有授予它的权限。 – Donna 2014-08-31 15:05:22
我有同样的问题，究其原因是，有人把粘着位在gdb的可执行文件：
cruiz> ls -l /usr/bin/gdb
-rwsr-sr-x 1 root root 4190760 2010-05-05 07:55 /usr/bin/gdb*
我改变了它（chmod 755 /usr/bin/gdb），现在它的工作原理。
前：
cruiz> gdb
...
(gdb) shell
csh: Permission denied.
变更后：
cruiz> gdb
(gdb) shell
cruiz>
我使用系统命令“睡眠”上面来说明我用我自己的代码，看到的行为。所以我不认为睡眠是根源的事实是一个问题。 – Donna 2014-08-30 21:54:02
你检查或修改.tcshr的权限吗？为什么它运行tcsh呢？ – user829755 2014-08-30 22:18:24
我没有检查.tcshrc的权限，并将它们更改为root - 这没有帮助。至于为什么GDB运行tcsh，我不知道。这对我来说非常神秘。我不想以root身份运行gdb，所以想要弄清楚发生了什么变化。我上面给出的例子在OSX下没有问题，所以问题不在于可执行文件的权限（看起来）。 – Donna 2014-08-31 04:24:20