[lkml]   [2000]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Allow debuger to examine real parent
Alan Cox <> writes:
> > This patch enables debugger to examine original parent of traced
> > process. That information is not available elsewhere.
> So how does ps get it then...

It doesn't. ps reports the tracing process as the parent, rather than
reporting the original parent as the parent. AFAIK, ps gets its info from
/proc, and you can verify that every occurrence of 'pptr' in the proc code is
'p_pptr' (referring to the parent) rather than p_opptr (referring to the
original parent).

[The only times when p_pptr != p_opptr is when a PTRACE_ATTACH happened, or
when CLONE_PTRACE was used.]

Although I'm the author of the patch, I don't think it's really the ultimate
correct solution to the problem. The correct solution, IMHO, is (within
userland) to always report the original parent in places where the parent is
currently being reported. This preserves the illusion that ptracing isn't
happening, for processes that don't care or need to know about it. For
processes that really *do* need to know, there should be a "special" way of
finding out--a new file in proc, maybe, or a new syscall or new ptrace

Since the full "correct" solution isn't required for SUBTERFUGUE, and since
I've heard that small, simple patches are easier to get into the kernel, I
just used a minimal solution.

> This seems surplus

As above, it's not. As far as I can tell, there's simply no other way of
finding this information out, short of dredging through kcore or something
similarly hideous.


Any sufficiently adverse technology is indistinguishable from Microsoft.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.075 / U:4.116 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site