From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Roland McGrath <roland@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Chris Evans <scarybeasts@gmail.com>,
David Howells <dhowells@redhat.com>,
Don Howard <dhoward@redhat.com>, Eugene Teo <eugene@redhat.com>,
Michael Kerrisk <mtk.manpages@googlemail.com>,
Tavis Ormandy <taviso@sdf.lonestar.org>,
Vitaly Mayatskikh <vmayatsk@redhat.com>,
stable@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] copy_process: fix CLONE_PARENT && ->exit_signal interaction
Date: Thu, 26 Feb 2009 22:59:46 +0100 [thread overview]
Message-ID: <20090226215945.GA12520@redhat.com> (raw)
In-Reply-To: <20090225212039.GA11883@redhat.com>
On 02/25, Oleg Nesterov wrote:
>
> On 02/25, Linus Torvalds wrote:
> >
> > > As I think I said before, I don't really know what the actual use case is
> > > for CLONE_PARENT without CLONE_THREAD. So it's easy to approve changing
> > > its behavior, but I do vaguely worry about who expected what behavior before.
> >
> > I think changing it is wrong.
>
> Perhaps. As I said, I don't know what is the expected behaviour. And in fact
> I can't think of the "obviously good" behaviour.
>
> > I can easily see somebody using CLONE_PARENT to get the correct getppid
> > semantics in the thread, and then setting the signal to zero to not make
> > the parent see the thread go away.
>
> ->exit_signal == 0 doesn't mean the thread silently goes away, it becomes
> a zombie (even if ->parent ignores SIGCHLD). We don't send the signal, but
> that is all.
>
> And if ->parent execs, we reset ->exit_signal to SIGCHLD anyway.
Really, how CLONE_PARENT + exit_signal==0 can be useful?
I still think this patch does the right change. Not because it fixes the
security problem, as I said I do not think the ability to send SIGKILL to
->parent is wrong from the security pov, even if child does setuid/etc,
the problem is that CLONE_PARENT can fool ->xxx_exec_id logic and we can
send SIGKILL after parent/child exec.
But because the current behaviour is just silly. Imho.
But of course, if this change can break the user-space applications, then
it should not be applied.
> > And quite
> > frankly, it would be good to try to see if there are other alternatives.
>
> Agreed. I thought about checking ->xxx_exec_id's in copy_process(),
> but doesn't look very nice...
I meant something like the patch below. But I don't like it.
Anybody has other ideas?
Oleg.
--- kernel/fork.c
+++ kernel/fork.c
@@ -1218,9 +1218,15 @@ static struct task_struct *copy_process(
set_task_cpu(p, smp_processor_id());
/* CLONE_PARENT re-uses the old parent */
- if (clone_flags & (CLONE_PARENT|CLONE_THREAD))
+ if (clone_flags & (CLONE_PARENT|CLONE_THREAD)) {
p->real_parent = current->real_parent;
- else
+ p->self_exec_id = p->parent_exec_id =
+ p->real_parent->self_exec_id;
+
+ if (current->parent_exec_id != current->real_parent->self_exec_id ||
+ current->self_exec_id != current->parent_exec_id)
+ p->exit_signal = SIGCHLD;
+ } else
p->real_parent = current;
spin_lock(¤t->sighand->siglock);
next prev parent reply other threads:[~2009-02-26 22:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-25 19:02 [PATCH 1/2] copy_process: fix CLONE_PARENT && ->exit_signal interaction Oleg Nesterov
2009-02-25 19:39 ` Roland McGrath
2009-02-25 19:48 ` Oleg Nesterov
2009-02-25 19:54 ` Roland McGrath
2009-02-25 20:06 ` Linus Torvalds
2009-02-25 21:20 ` Oleg Nesterov
2009-02-25 21:34 ` [stable] " Greg KH
2009-02-26 21:59 ` Oleg Nesterov [this message]
2009-02-26 22:12 ` Linus Torvalds
2009-02-26 22:30 ` Oleg Nesterov
2009-02-26 22:43 ` Linus Torvalds
2009-03-02 21:22 ` [PATCH] copy_process: fix CLONE_PARENT && parent_exec_id interaction Oleg Nesterov
2009-03-02 21:33 ` Linus Torvalds
2009-03-02 21:58 ` Oleg Nesterov
2009-03-09 16:45 ` David Howells
2009-03-09 18:33 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090226215945.GA12520@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dhoward@redhat.com \
--cc=dhowells@redhat.com \
--cc=eugene@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@googlemail.com \
--cc=roland@redhat.com \
--cc=scarybeasts@gmail.com \
--cc=stable@kernel.org \
--cc=taviso@sdf.lonestar.org \
--cc=torvalds@linux-foundation.org \
--cc=vmayatsk@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox