strace: operation not permitted, ptrace_scope incorrect

Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached.

We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today!

Profile image of Mattias Geniar

Mattias Geniar, October 22, 2019

Follow me on Twitter as @mattiasgeniar

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.



Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.