public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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(&current->sighand->siglock);


  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