CODEWITHSUNDEEP
linuxgdb
Donna
Donna

Reputation: 1550

Why is gdb requiring root permission to debug user programs?

I have been using gdb quite successfully for a while, but I recently upgraded my version of Ubuntu, and now it seems that I can only get gdb to successfully run my program if I run as root. That is, 

~ %  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)

fails, whereas

~ %  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)

works. One clue is that in the first case, the gdb startup doesn't run my .tcshrc file, whereas in the second case it does.

It seems that this is a simple permissions issue, which I must have fixed at one time, because in the past, I have never needed to run gdb as root. After much googling, however, I wasn't able to find what I might have done (if I did in fact do something). One possible fix - set ptrace permissions - didn't seem to work.

Is there something that needs to be done to allow gdb to run programs without root privileges? I know in OSX, gdb has to be codesigned. Is there something similar for Ubuntu/Linux?

Upvotes: 7

Views: 23263

Answers (7)

0xan0ead
0xan0ead

Reputation: 1

I faced this issue before, and files from /usr/bin/gdb* didn't have execution permissions. This happened after I have installed peda, pwndbg and gef.

# chmod +x /usr/bin/gdb-*

Upvotes: 0

user214810
user214810

Reputation: 11

I specified Linux in the launch.json file, via the LaunchCompleteCommand...

MS has 3 different ways to specify the CPU... Windows, Linux or OSx

From https://code.visualstudio.com/docs/cpp/launch-json-reference

    "launchCompleteCommand": "exec-run",
      "linux": {
        "MIMode": "gdb",
        "miDebuggerPath": "/usr/bin/gdb"
      },

In my launch.json file, this LaunchCompleteCommand section was pasted in after the setupCommands section.

Upvotes: 0

tinyboyz
tinyboyz

Reputation: 31

Check if your program has executable privileges.

ls -l .
-rw-r--r-- 1 opt opt 30010 Aug 16 16:13 test

Something like 'test' maybe caused that when you debug it.

Upvotes: 1

Carlos
Carlos

Reputation: 1

I had the same problem and the reason was that someone had set the sticky bit in the gdb executable:

cruiz> ls -l /usr/bin/gdb

-rwsr-sr-x 1 root root 4190760 2010-05-05 07:55 /usr/bin/gdb*

I changed it (chmod 755 /usr/bin/gdb) and now it works.

Before:

cruiz> gdb
...

(gdb) shell

csh: Permission denied.

After the change:

cruiz> gdb

(gdb) shell

cruiz>

Upvotes: -1

Donna
Donna

Reputation: 1550

This isn't a complete answer, but things are becoming clearer. The tip above was very helpful. I created the following .gdbinit file

show environment SHELL
file /bin/echo
run 'Goodbye'

and the results were interesting. If SHELL=/usr/tcsh, I get a permissions error, i.e. 

~ %  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.

Unsetting the shell variable works : 

~ %  unsetenv SHELL
~ %  gdb -q -batch
Environment variable "SHELL" not defined.
Goodbye
[Inferior 1 (process 6992) exited normally]

In this case, run uses /bin/sh to expand the argument list. Setting SHELL to /bin/bash or /bin/dash will use those shells to expand the argument list, e.g. 

~ %  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]

Oddly, the "no loadable sections' error only happens when the shell variable is explicitly set. Another mystery.

Why /bin/tcsh doesn't work is still baffling. In my case, the permissions on /bin/tcsh are 

~ %  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

The problem could also be something in my .tcshrc file that is causing the shell to crash in this non-interactive mode.

Upvotes: 2

Donna
Donna

Reputation: 1550

I changed my login shell to bash and gdb no longer needs root permission to debug. Here is the latest :

My .gdbinit file:

(bash) ~ % more .gdbinit
show environment SHELL
file /bin/echo
run 'running .gdbinit'
(bash) ~ %

and the results of running gdb :

(bash) ~ % gdb -q -batch
SHELL = /bin/bash
running .gdbinit
[Inferior 1 (process 3174) exited normally]
(bash) ~ %

I still don't understand why tcsh didn't work, though, and am curious to know. So if anyone has a possible explanation, please comment.

Upvotes: 3

user829755
user829755

Reputation: 1588

here are some ideas for debugging the gdb problem. comments aren't really feasible for such things, so I put them into an answer.

try the -n option to make sure no init file is loaded.

use the echo program instead of sleep 60 to make debugging simpler (the SIGINT thing in your example is probably specific to the sleep program.

run gdb -batch and put the rest into ~/.gdbinit:

file /bin/echo
run

add set verbose on.

don't forget to clean up ~/.gdbinit when done.

Upvotes: 2

Related Questions