2

I have a CentOS 7 system. I need to attach my GDB to an already running application, but get the (apparently usual) "ptrace: Operation not permitted." error. Running GDB as root prevents the error, but I would rather not resort to this.

I have researched the issue and did find multiple answers stating that you simply needed to either modify /proc/sys/kernel/yama/ptrace_scope with the value 0 or go for a permanent fix regarding the file /etc/sysctl.d/10-ptrace.conf...

Well, apparently everyone assumes you are using YAMA, which seems not to be the case over here. Yet, I have not been able to find what to do in my situation yet.

I have checked, and it seems my system is configured with SELinux, but it is not enabled. My Kernel boot settings include the flag selinux=0, and the command

grep CONFIG_SECURITY /boot/config-`uname -r`

reads

# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
CONFIG_SECURITY_SECURELEVEL=y
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set

Finally, getsebool deny_ptrace returns getsebool: SELinux is disabled.

From my understanding, no LSM is currently enabled on my system, yet I still get the ptrace limitations. I am here clueless about where to look next, or what even causes the ptrace limitation at this point.

Is the fact that the setuid bit is set on my executable file potentially causing this issue? Both gdb and the application are themselves launched using the same user, without any super-user privileges specifically added to either. ps -eouid,comm also shows both as having the same uid. Only the application is run using the setuid bit, and the file belongs to root:root.

  • Are you running gdb as the same user as the app? Only root can ptrace processes that aren't his/her own. – derobert May 15 '17 at 20:56
  • As far as I can tell, it doesn't seem to fail for sleep. I haven't tried extensively yet. – Vincent Fortin May 15 '17 at 21:30
  • Is the fact that the setuid bit is set on my executable file potentially causing this issue? Both gdb and the application are themselves launched using the same user, without any super-user privileges specifically added to either. ps -eouid,comm also shows both as having the same uid. Only the application is run using the setuid bit, and the file belongs to root:root. – Vincent Fortin May 15 '17 at 21:34
  • The problem is that the executable is setuid. Only root can debug setuid binaries, since if you can debug a program then you get its privileges. You should have mentioned that from the start! It's obviously an important point. – Gilles May 15 '17 at 23:29
  • This is indeed something I overlooked, even in my own search prior to this post. Thanks! – Vincent Fortin May 16 '17 at 13:38
3

Debugging a program that has privileges effectively gives the debugger the same privileges. Therefore, regardless of any security settings, debugging a program that has extra privileges must require the debugger to have at least all of these privileges. For example, a setuid program has the privileges of both the original and the target user, so the debugger has to have the privileges of both users. In practice, this means that the debugger must be root. On Linux, it's enough to give the debugger the capability CAP_SYS_PTRACE (this doesn't reduce the debugger's effective privileges, but it means that the debugger won't e.g. accidentally overwrite files of another user).

It's generally more convenient to debug the program while running without extra privileges. Adjust file permissions, paths and so on accordingly. If you need to debug the program in real conditions with the privileges then the debugger needs to run as root. On Linux, this can be root in a user namespace that contains the two users involved.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.