I’m trying to debug a weird problem with Python script running as root, and struggling to make progress because ptrace seems to be disabled by some kind of security restriction. The usual fix for this is setting /proc/sys/kernel/yama/ptrace_scope to 0, but I’ve already done that, so I’m guessing it’s some other LSM-related restriction.
An example, as the admin user:
admin@xyz[~]$ gdb /bin/true
GNU gdb (Debian 13.1-3) 13.1
...
Reading symbols from /bin/true...
(No debugging symbols found in /bin/true)
(gdb) run
Starting program: /usr/bin/true
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 1 (process 2476538) exited normally]
(gdb) quit
As root, however:
root@xyz[/home/admin]# gdb /bin/true
...
(gdb) run
Starting program: /usr/bin/true
warning: Could not trace the inferior process.
warning: ptrace: Operation not permitted
During startup program exited with code 127.
Hi.
This is due to the sudo seccomp filter. Remove/comment lines
Defaults log_subcmds
Defaults log_format=json
in /etc/sudoers using sudo visudo in Linux shell.
I plan to create a ticket in Jira to update /etc/sudo.conf because such log_subcmds usage is not recommended:
## Uncomment to disable intercept and log_subcmds for debuggers and
## tracers. Otherwise, anything that uses ptrace(2) will be unable
## to run under sudo if intercept_type is set to "trace".
# Defaults!DEBUGGERS !intercept, !log_subcmds
##
## Uncomment to disable intercept and log_subcmds for package managers.
## Some package scripts run a huge number of commands, which is made
## slower by these options and also can clutter up the logs.
# Defaults!PKGMAN !intercept, !log_subcmds
#Otherwise, anything that uses ptrace(2) will be unable to run under sudo if intercept_type is set to "trace".
