Date: Fri, 21 Jan 2005 13:31:46 -0800
Message-Id: <200501212131.j0LLVkJ8013886@magilla.sf.frob.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Roland McGrath <roland@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrea Arcangeli <andrea@cpushare.com>, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org
Subject: Re: seccomp for 2.6.11-rc1-bk8
In-Reply-To: Ingo Molnar's message of  Friday, 21 January 2005 13:55:58 +0100 <20050121125558.GA5596@elte.hu>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1057
Lines: 23

> maybe this could even be fit into existing ptrace semantics, without any
> need for PTRACE_ATTACH_JAIL. What we need is to catch the case where a
> ptraced child is running (i.e. the signal_wake_up() has already been
> done, and the parent is waiting for the child to stop again), and the
> ptrace parent is killed unexpectedly.  Would it be a correct fix to just
> unconditionally stop the child in this case (and leave it hanging in
> such a state)? Or to kill it right away?

That's the same as the case of the debugger dying or being killed by hand.
When gdb has a bug, people want to be able to kill it and get on with using
their program, not have their program always be killed too.

If you add this feature, it makes most sense IMHO to use PTRACE_SETOPTIONS
as the way to request it.  


Thanks,
Roland
-
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/