On 8/26/2014 4:23 PM, John Baldwin wrote: > On Tuesday, August 26, 2014 3:32:10 pm John-Mark Gurney wrote: >> John Baldwin wrote this message on Tue, Aug 26, 2014 at 15:09 -0400: >>> On Monday, August 25, 2014 6:30:34 pm John-Mark Gurney wrote: >>>> John Baldwin wrote this message on Mon, Aug 25, 2014 at 13:35 -0400: >>>>> On Monday, August 25, 2014 07:02:41 PM Mateusz Guzik wrote: >>>>>> On Mon, Aug 25, 2014 at 10:23:19AM -0400, John Baldwin wrote: >>>>>>> On Sunday, August 24, 2014 09:04:09 AM Mateusz Guzik wrote: >>>>>>>> Author: mjg >>>>>>>> Date: Sun Aug 24 09:04:09 2014 >>>>>>>> New Revision: 270444 >>>>>>>> URL: http://svnweb.freebsd.org/changeset/base/270444 >>>>>>>> >>>>>>>> Log: >>>>>>>> Fix getppid for traced processes. >>>>>>>> >>>>>>>> Traced processes always have the tracer set as the parent. >>>>>>>> Utilize proc_realparent to obtain the right process when needed. >>>>>>> >>>>>>> Are you sure this won't break things? I know of several applications >>>>>>> that >>>>>>> expect a debugger to be the parent when attached and change behavior as >>>>>>> a >>>>>>> result (e.g. inserting a breakpoint on an assertion failure rather than >>>>>>> generating a core). >>>>>> >>>>>> Well, this is what linux and solaris do. >>>>> >>>>> Interesting. >>>>> >>>>>> I don't feel strongly about this change. If you really want I'm happy to >>>>>> revert. >>>>> >>>>> In general I'd like to someday have the debugger-debuggee relationship >>>>> not >>>>> override parent-child and this is a step in that direction. However, >>>>> this >>>>> will break existing applications, so this needs to be clearly documented >>>>> in >>>>> the release notes. In addition, we should probably advertise how a >>>>> process >>>>> can correctly determine if it is being run under a debugger (right now >>>>> you can >>>>> do 'getppid()' and use strcmp or strstr on the p_comm of that pid so you >>>>> can >>>>> do different things for "gdb" vs "gcore", etc. so just checking P_TRACED >>>>> from >>>>> kinfo_proc wouldn't be equivalent in functionality) >>>> >>>> But what about when you attach gdb to a running process... That >>>> doesn't magicly make the now debugged process a child of gdb does it? >>> >>> % cat hello.c >>> #include <stdio.h> >>> >>> int >>> main() >>> { >>> printf("hello world\n"); >>> (void)getchar(); >>> return (0); >>> } >>> % cc -g hello.c -o hello >>> % ./hello >>> hello world >>> load: 9.81 cmd: hello 42599 [ttyin] 1.67r 0.00u 0.00s 0% 1056k >>> >>> < different window > >>> >>> % ps -O ppid -p `pgrep hello` >>> PID PPID TT STAT TIME COMMAND >>> 42599 5340 16 I+ 0:00.00 ./hello >>> % gdb hello `pgrep hello` >>> GNU gdb 6.1.1 [FreeBSD] >>> ... >>> (gdb) <hit Ctrl-Z> >>> Suspended >>> % ps -O ppid -p `pgrep hello` >>> PID PPID TT STAT TIME COMMAND >>> 42599 45079 16 TX+ 0:00.00 ./hello >> >> Wow, learn something new every day... >> >> But doesn't that break apps that use getppid to signal their parent >> that forked them? > > Until mjg@'s commit, yes. It's been that way in FreeBSD at least for > as long as I can remember. Certainly back to 4.x. >
Fun things can happen (local DoS) when you trace your own parent too. Recently fixed by other commits. Easily thwarted by security.bsd.unprivileged_proc_debug=0. -- Regards, Bryan Drewery
signature.asc
Description: OpenPGP digital signature