Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
Jesse Pollard (email@example.com)
Tue, 17 Apr 2001 09:26:26 -0500 (CDT)
> >"Adam J. Richter" <firstname.lastname@example.org> said:
> >> I suppose that running the child first also has a minor
> >> advantage for clone() in that it should make programs that spawn lots
> >> of threads to do little bits of work behave better on machines with a
> There is another issue with this proposition. I have begun to write (free
> time, slow pace) an userland sandbox which allows me to prevent a process
> and its childs to perform some given actions, like removing files or
> writing in some directories. This works by ptrace-ing the process,
> modifying system calls and faking return values. It also needs,
> obviously, to ptrace-attach childs of the sandboxed process. When the
> parent in a fork runs first, the sandbox program has time to
> ptrace-attach the child before it does any system call. Obviously, if the
> child runs first, this is no longer the case.
> If it is decided that the child should run first in a fork, there should
> be a way to reliably ptrace-attach it before it can do anything.
> By the way, I tried to solve this problem in my sandbox program by
> masqerading any fork call into a clone system call with the flag
> CLONE_PTRACE. I had hoped that the child would in this way start already
> ptraced. However, this didn't work as expected. The child did start in a
> ptraced state, but the owner of the trace was its parent (which issued
> the fork), and not my sandbox process which was ptracing this parent. I
> find that this behaviour is really weird and useless. I could simulate
> the current behaviour simply by calling ptrace(TRACE_ME,..) in the child.
> What is the real use of the CLONE_PTRACE flag ?
I believe it allows the debugger to start the process to be debugged.
Jesse I Pollard, II
Any opinions expressed are solely my own.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/