4

I have a server application that can be summoned for the client using inetd. However, if I try to attach to the server process that was launched with inetd, I get the following response: ptrace: Operation not permitted.

gdb --annotate=3 /my/app/here <processId>

Current directory is /usr/local/bin/
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Reading symbols from /usr/local/bin/flumed...done.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
Attaching to program: /my/app/here, process <processId>
ptrace: Operation not permitted.
/usr/local/bin/<processId>: No such file or directory.
(gdb)
WilliamKF
  • 41,123
  • 68
  • 193
  • 295
  • 1
    `ptrace: Operation not permitted.` As Alex suggested, run GDB as the same UID as the service or as root. – ephemient Oct 19 '09 at 03:39
  • No, not root, but ps shows the pid owned by myself. – WilliamKF Oct 19 '09 at 14:43
  • Are you on a system with SELinux, AppArmor, or any other security framework enabled? Also, it is possible for an application itself to prevent `ptrace` from working, which blocks all attempts at debugging... is this a proprietary app? – ephemient Oct 19 '09 at 17:51
  • It is my own app. It debugs fine when not launched via inetd, for example when launched via ssh, I can attach fine. – WilliamKF Oct 20 '09 at 00:34

5 Answers5

8

Solution for me was this:

echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
DinGODzilla
  • 1,611
  • 4
  • 21
  • 34
  • 2
    That is a solution that works on Ubuntu, but not on Debian as far as I know. See http://blog.mellenthin.de/archives/2010/10/18/gdb-attach-fails-with-ptrace-operation-not-permitted/ and https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace%20Protection – Ztyx Jul 14 '11 at 08:21
2

Further to what tgoodhart said, other ptrace users like /usr/bin/strace will also block gdb.

Emil Mikulic
  • 131
  • 1
  • 5
2

Apparently, things get funky with inetd where the userid is not root. You end up with a process with weird permissions. For example, you are unable to read /proc/self/exe even though the permissions are 777. I suspect this issue is more of the same. Even though I'm the userid of the process, I don't have permissions. Using root for gdb is a work around.

WilliamKF
  • 41,123
  • 68
  • 193
  • 295
0

I have also seen this problem occur when multiple instances of gdb are running at the same time, usually because I failed to close gdb correctly. Closing these leaked instances fixed the problem.

tgoodhart
  • 3,111
  • 26
  • 37
-1

Pls run the following command to solve ur problem:

sudo chmod +s /usr/bin/gdb

SimonZC
  • 59
  • 3