>"Adam J. Richter" <adam@yggdrasil.com> 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 ?
Éric Brunet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 23 2001 - 21:00:21 EST