strace: operation not permitted, ptrace_scope incorrect

When using strace on a server, you might get this error message when you try to attach to a running process.

$ strace -f -p 13239
strace: attach: ptrace(PTRACE_SEIZE, 13239): Operation not permitted
strace: Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf: Operation not permitted

Alas, it doesn’t work!

Here’s why: your current user doesn’t have permissions to trace a running process. Here are some workarounds.

Strace a new process instead#

If you have the ability, you can strace a new program instead. This might not always be an option, but it works like this.

$ strace -f ./binary

You’d start ./binary again and strace that process.

Get root access#

Alternative, get root level privileges to strace running processes. Makes sense, but might not always be an option in your environment.

Allow users to strace other processes with the same uid#

You can also change a setting to allow a user to strace processes that have the same uid. In other words: allow a user to strace a processes from itself.

To do so, it requires a root-level change (aka: a root level admin needs to change this).

Have a look at the file /etc/sysctl.d/10-ptrace.conf

$ cat /etc/sysctl.d/10-ptrace.conf
# The PTRACE system is used for debugging.  With it, a single user process
# can attach to any other dumpable process owned by the same user.  In the
# case of malicious software, it is possible to use PTRACE to access
# credentials that exist in memory (re-using existing SSH connections,
# extracting GPG agent information, etc).
#
# A PTRACE scope of "0" is the more permissive mode.  A scope of "1" limits
# PTRACE only to direct child processes (e.g. "gdb name-of-program" and
# "strace -f name-of-program" work, but gdb's "attach" and "strace -fp $PID"
# do not).  The PTRACE scope is ignored when a user has CAP_SYS_PTRACE, so
# "sudo strace -fp $PID" will work as before.  For more details see:
# https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace
#
# For applications launching crash handlers that need PTRACE, exceptions can
# be registered by the debugee by declaring in the segfault handler
# specifically which process will be using PTRACE on the debugee:
#   prctl(PR_SET_PTRACER, debugger_pid, 0, 0, 0);
#
# In general, PTRACE is not needed for the average running Ubuntu system.
# To that end, the default is to set the PTRACE scope to "1".  This value
# may not be appropriate for developers or servers with only admin accounts.
kernel.yama.ptrace_scope = 1

If you change kernel.yama.ptrace_scope to 0 and reboot the system, you’ll now be allowed to strace processes of your own uid.