All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: sukadev@linux.vnet.ibm.com
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Pavel Emelyanov <xemul@openvz.org>,
	daniel@hozac.com, Nadia Derbey <Nadia.Derbey@bull.net>,
	serue@us.ibm.com, clg@fr.ibm.com,
	Containers <containers@lists.osdl.org>,
	sukadev@us.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: Signals to cinit
Date: Mon, 10 Nov 2008 20:32:28 +0100	[thread overview]
Message-ID: <20081110193228.GA15519@redhat.com> (raw)
In-Reply-To: <20081110173839.GA11121@redhat.com>

(lkml cced because containers list's archive is not useable)

On 11/10, Oleg Nesterov wrote:
>
> On 11/01, sukadev@linux.vnet.ibm.com wrote:
> >
> > Other approaches to try ?
>
> I think we should try to do something simple, even if not perfect. Because
> most users do not care about this problem since they do not use containers
> at all. It would be very sad to add intrusive changes to the code.
>
> I think we should fix another problem first. send_signal()->copy_siginfo()
> path must be changed anyway, when the signal comes from the parent ns we
> report the "wrong" si_code/si_pid, yes? So, somehow send_signal() must
> have "bool from_parent_ns" (or whatever) annyway.
>
> Now, let's forget forget for a moment that send_signal()->__sigqueue_alloc()
> can fail.
>
> I think we should encode this "from_parent_ns" into "struct siginfo". I do
> not think it is good idea to extend this structure, I think we can introduce
> SI_FROM_PARENT_NS or we perhaps can use "SI_FROMUSER(info) && info->si_pid == 0".
> Or something. yes, sys_rt_sigqueueinfo() is problematic...
>
> Now, copy_process(CLONE_NEWPID) sets child->signal |= SIGNAL_UNKILLABLE, this
> protects cinit from unwanted signals. Then we change get_signal_to_deliver()
>
> 	-	if (unlikely(signal->flags & SIGNAL_UNKILLABLE) &&
> 	+	if (unlikely(signal->flags & SIGNAL_UNKILLABLE) && !siginfo_from_parent_ns(info)
>
> and now we can kill cinit from parent ns. This needs more checks if we want
> to stop/strace it, but perhaps this is enough for the start. Note that we
> do not need to change complete_signal(), at least for now, the code under
> "if (sig_fatal(p, sig)" is just optimization.
>
>
> So, afaics, the only real problem is how we can handle the case when
> __sigqueue_alloc() fails. I think for the start we can just return
> -ENOMEM in this case (when from_parent_ns == T). Then we can improve
> this behaviour. We can change complete_signal() to ensure that the
> fatal signal from the upper ns always kills cinit, and in this case
> we ignore the the failed __sigqueue_alloc(). This way at least SIGKILL
> always works.
>
> Yes, this is not perfect, and it is very possible I missed something
> else. But simple.

But how can send_signal() know that the signal comes from the upper ns?
This is not trivial, we can't blindly use current to check. The signal
can be sent from irq/workqueue/etc.

Perhaps we can start with something like the patch below. Not that I like
it very much though. We should really place this code under
CONFIG_I_DO_CARE_ABOUT_NAMESPACES ;)

Oleg.

--- K-IS/kernel/signal.c~T	2008-11-10 19:21:17.000000000 +0100
+++ K-IS/kernel/signal.c	2008-11-10 20:31:24.000000000 +0100
@@ -798,11 +798,19 @@ static inline int legacy_queue(struct si
 	return (sig < SIGRTMIN) && sigismember(&signals->signal, sig);
 }
 
+#define SIG_FROM_USER	INT_MIN		/* MSB */
+
 static int send_signal(int sig, struct siginfo *info, struct task_struct *t,
 			int group)
 {
 	struct sigpending *pending;
 	struct sigqueue *q;
+	int from_ancestor_ns;
+
+	from_ancestor_ns = !is_si_special(info) &&
+		(info->si_signo | SIG_FROM_USER) &&
+		/* if t can't see us we are from parent ns */
+		task_pid_nr_ns(current, t->current->nsproxy->pid_ns) <= 0;
 
 	trace_sched_signal_send(sig, t);
 
@@ -855,6 +863,7 @@ static int send_signal(int sig, struct s
 			break;
 		default:
 			copy_siginfo(&q->info, info);
+			q->info.si_signo &= ~SIG_FROM_USER;
 			break;
 		}
 	} else if (!is_si_special(info)) {
@@ -2207,7 +2216,7 @@ sys_kill(pid_t pid, int sig)
 {
 	struct siginfo info;
 
-	info.si_signo = sig;
+	info.si_signo = sig | SIG_FROM_USER;
 	info.si_errno = 0;
 	info.si_code = SI_USER;
 	info.si_pid = task_tgid_vnr(current);
@@ -2224,7 +2233,7 @@ static int do_tkill(pid_t tgid, pid_t pi
 	unsigned long flags;
 
 	error = -ESRCH;
-	info.si_signo = sig;
+	info.si_signo = sig | SIG_FROM_USER;
 	info.si_errno = 0;
 	info.si_code = SI_TKILL;
 	info.si_pid = task_tgid_vnr(current);
@@ -2296,7 +2305,7 @@ sys_rt_sigqueueinfo(pid_t pid, int sig, 
 	   Nor can they impersonate a kill(), which adds source info.  */
 	if (info.si_code >= 0)
 		return -EPERM;
-	info.si_signo = sig;
+	info.si_signo = sig | SIG_FROM_USER;
 
 	/* POSIX.1b doesn't mention process groups.  */
 	return kill_proc_info(sig, &info, pid);

  parent reply	other threads:[~2008-11-10 19:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-01 18:05 Signals to cinit sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
     [not found] ` <20081101180505.GA24268-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-11-10 17:38   ` Oleg Nesterov
     [not found]     ` <20081110173839.GA11121-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-11-10 18:00       ` Oleg Nesterov
2008-11-10 19:32     ` Oleg Nesterov [this message]
2008-11-10 23:27       ` sukadev
2008-11-12 14:52         ` Oleg Nesterov
2008-11-12 16:12           ` Oleg Nesterov
2008-11-12 16:49           ` Serge E. Hallyn
2008-11-12 18:12             ` Sukadev Bhattiprolu
2008-11-12 19:06               ` Serge E. Hallyn
2008-11-11  2:24       ` sukadev
2008-11-12 15:05         ` Oleg Nesterov
2008-11-12 19:04           ` Sukadev Bhattiprolu
2008-11-14 17:26             ` Oleg Nesterov
2008-11-12 16:53       ` Serge E. Hallyn
2008-11-13 19:10       ` Sukadev Bhattiprolu

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=20081110193228.GA15519@redhat.com \
    --to=oleg@redhat.com \
    --cc=Nadia.Derbey@bull.net \
    --cc=clg@fr.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=daniel@hozac.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=serue@us.ibm.com \
    --cc=sukadev@linux.vnet.ibm.com \
    --cc=sukadev@us.ibm.com \
    --cc=xemul@openvz.org \
    /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.