1

From https://man7.org/linux/man-pages/man2/prctl.2.html the operation is documented with:

   PR_SET_PTRACER (since Linux 3.4)
          This is meaningful only when the Yama LSM is enabled and
          in mode 1 ("restricted ptrace", visible via
          /proc/sys/kernel/yama/ptrace_scope).  When a "ptracer
          process ID" is passed in arg2, the caller is declaring
          that the ptracer process can ptrace(2) the calling process
          as if it were a direct process ancestor.  Each
          PR_SET_PTRACER operation replaces the previous "ptracer
          process ID".  Employing PR_SET_PTRACER with arg2 set to 0
          clears the caller's "ptracer process ID".  If arg2 is
          PR_SET_PTRACER_ANY, the ptrace restrictions introduced by
          Yama are effectively disabled for the calling process.

          For further information, see the kernel source file
          Documentation/admin-guide/LSM/Yama.rst (or
          Documentation/security/Yama.txt before Linux 4.13).

"ptracer process ID" would appear to refer to the process ID of the process we wish to grant ptrace permission.

However on https://man7.org/linux/man-pages/man2/ptrace.2.html

   A tracee first needs to be attached to the tracer.  Attachment
   and subsequent commands are per thread: in a multithreaded
   process, every thread can be individually attached to a
   (potentially different) tracer, or left not attached and thus not
   debugged.  Therefore, "tracee" always means "(one) thread", never
   "a (possibly multithreaded) process".  Ptrace commands are always
   sent to a specific tracee using a call of the form

       ptrace(PTRACE_foo, pid, ...)

   where pid is the thread ID of the corresponding Linux thread.

Which would seem to suggest that despite the value being named pid it is not the process id but rather than thread id.

Does "ptracer process ID" mean the thread id?

Jonathan Woollett-light
  • 2,813
  • 5
  • 30
  • 58
  • There doesn't seem to be any contradiction -- _tracee_ is a thread, _tracer_ is a process. – Employed Russian Mar 05 '23 at 18:16
  • from source code it seems like you could pass thread id as "ptracer process ID" making a thread to be tracer and only that thread (and descendant processes/threads) would have access unless that is main thread id in which case all other threads would have access also. worth noting that it doesn't matter from which thread you call prctl as the tracer is set per tracee process (not thread). – Kazz Mar 05 '23 at 20:32

1 Answers1

0

Does "ptracer process ID" mean the thread id?

It can if the tracer has multiple threads itself. But, most tracers don't use multiple threads, so it's a bit of a moot point. IMO, having a tracer with multiple threads complicates the tracer with little benefit over having a single process/thread tracer than keeps track of multiple tracees (as gdb and strace do).

Under linux, once spawned, threads are largely indistinguishable from processes. For more on this, see my answer: How are user-level threads scheduled/created, and how are kernel level threads created?

When connecting a tracer to a tracee, you probably don't want to use PR_SET_PTRACER as it's linux specific and must be enabled in kernel:

This is meaningful only when the Yama LSM is enabled and in mode 1 ("restricted ptrace", visible via /proc/sys/kernel/yama/ptrace_scope).

If you have an untraced process, and you want to attach a tracer to it after the tracee is running, you probably want the [proposed] tracer to use ptrace with PTRACE_ATTACH or PTRACE_SEIZE. It isn't clear to me that PR_SET_PTRACER would do all the setup that PTRACE_ATTACH/PTRACE_SEIZE would do.

So, you may have to do PTRACE_ATTACH first. Then, if enabled in the YAMA security module, you could transfer the tracing to another process/thread with PR_SET_PTRACER. But, I question the utility of this without some very specific requirements.

I'm not sure about this, but the target pid of the ptrace call can be a (sub)thread id. But, the man page talks about process id. Looking in the kernel source for ptrace, a cursory examination of the code seems to support the idea that it's a task id.

But, you probably want to attach to the parent process, so all threads will be attached. Tracing a single thread within a thread group doesn't make a lot of sense.

Again, I'm not sure if attaching to a tracee process will attach to all its threads. You may have to walk the tree of threads and attach them individually.

Craig Estey
  • 30,627
  • 4
  • 24
  • 48