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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.