All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: oleg@redhat.com, ebiederm@xmission.com, roland@redhat.com,
	bastian@waldi.eu.org
Cc: daniel@hozac.com, xemul@openvz.org, containers@lists.osdl.org,
	linux-kernel@vger.kernel.org
Subject: [RFC][PATCH 3/7][v4] Define siginfo_from_ancestor_ns()
Date: Wed, 24 Dec 2008 03:51:24 -0800	[thread overview]
Message-ID: <20081224115124.GC8020@us.ibm.com> (raw)
In-Reply-To: <20081224114414.GA7879@us.ibm.com>


From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Subject: [RFC][PATCH 3/7][v4] Define siginfo_from_ancestor_ns()

Determine if sender of a signal is from an ancestor namespace. This
function will be used in a follow-on patch.

This is an early/lightly tested RFC patch. Would it be safe to implement
siginfo_from_user() as below and then use it dereference the pid
namespace of sender ?

This is based on discussions on the patch from Oleg Nesterov and me
http://lkml.org/lkml/2008/11/25/462.

Changelog[v2]:
	- siginfo_from_ancestor_ns() is fairly clean and it does not need
	  to be under CONFIG_PID_NS. Only siginfo_from_user() needs to be.
	- Warn if rt_sigqueueinfo() uses SI_ASYNCIO.
	- Added a check for pid-ns of receiver being NULL (in case it is
	  exiting).

Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
 kernel/signal.c |   67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 67 insertions(+), 0 deletions(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index 55f41b6..0011f99 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -820,6 +820,56 @@ static inline int legacy_queue(struct sigpending *signals, int sig)
 {
 	return (sig < SIGRTMIN) && sigismember(&signals->signal, sig);
 }
+/*
+ * Return 1 if this signal originated directly from a user process (i.e via
+ * kill(), tkill(), sigqueue()).  Return 0 otherwise.
+ *
+ * TODO:
+ * 	  To make this less hacky, make SI_ASYNCIO a kernel signal (and
+ * 	  remove the warning in sys_rt_sigqueueinfo()).
+ */
+#ifdef CONFIG_PID_NS
+static inline int siginfo_from_user(siginfo_t *info)
+{
+	if (!is_si_special(info) && SI_FROMUSER(info) &&
+				info->si_code != SI_ASYNCIO)
+		return 1;
+
+	return 0;
+}
+#else
+static inline int siginfo_from_user(siginfo_t *info)
+{
+	return 0;
+}
+#endif
+
+static inline int siginfo_from_ancestor_ns(struct task_struct *t,
+                       siginfo_t *info)
+{
+	struct pid_namespace *ns;
+
+	/*
+	 * Ensure signal is from user-space before checking pid namespace
+	 */
+	if (siginfo_from_user(info)) {
+		/*
+		 * If we do not have a pid in the receiver's namespace,
+		 * we must be an ancestor of the receiver. 
+		 *
+		 * CHECK:
+		 * 	If receiver is exiting, ns == NULL, signal will be
+		 * 	queued but ignored (wants_signal() is FALSES). For
+		 * 	compatibility with current behavior, assume it is
+		 * 	from ancestor and queue the signal anyway ?
+		 */
+		ns = task_active_pid_ns(t);
+		if (!ns || task_pid_nr_ns(current, ns) <= 0)
+			return 1;
+	}
+
+	return 0;
+}
 
 static int send_signal(int sig, struct siginfo *info, struct task_struct *t,
 			int group)
@@ -2312,6 +2362,20 @@ sys_tkill(pid_t pid, int sig)
 	return do_tkill(0, pid, sig);
 }
 
+#ifdef CONFIG_PID_NS
+/*
+ * siginfo_from_user() assumes that si_code SI_ASYNCIO comes only from
+ * within the kernel. If an application is passing in SI_ASYNCIO we 
+ * want to know about it.
+ */
+static void warn_on_asyncio(siginfo_t *info)
+{
+	WARN_ON_ONCE(info->si_code == SI_ASYNCIO);
+}
+#else
+#define warn_on_asyncio(info)	{}
+#endif
+
 asmlinkage long
 sys_rt_sigqueueinfo(pid_t pid, int sig, siginfo_t __user *uinfo)
 {
@@ -2324,6 +2388,9 @@ sys_rt_sigqueueinfo(pid_t pid, int sig, siginfo_t __user *uinfo)
 	   Nor can they impersonate a kill(), which adds source info.  */
 	if (info.si_code >= 0)
 		return -EPERM;
+
+	warn_on_asyncio(&info);
+
 	info.si_signo = sig;
 
 	/* POSIX.1b doesn't mention process groups.  */
-- 
1.5.2.5

  parent reply	other threads:[~2008-12-24 11:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-24 11:44 [PATCH 0/7][v4] Container-init signal semantics Sukadev Bhattiprolu
2008-12-24 11:50 ` [RFC][PATCH 1/7][v4] Remove 'handler' parameter to tracehook functions Sukadev Bhattiprolu
2008-12-24 11:50 ` [RFC][PATCH 2/7][v4] Protect init from unwanted signals more Sukadev Bhattiprolu
     [not found]   ` <20081224115047.GB8020-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-12-24 16:35     ` Oleg Nesterov
2008-12-24 16:35       ` Oleg Nesterov
2008-12-24 21:11       ` Sukadev Bhattiprolu
2008-12-24 11:51 ` Sukadev Bhattiprolu [this message]
2008-12-24 16:28   ` [RFC][PATCH 3/7][v4] Define siginfo_from_ancestor_ns() Oleg Nesterov
     [not found]     ` <20081224162823.GE11593-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-12-24 21:24       ` Sukadev Bhattiprolu
2008-12-24 21:24         ` Sukadev Bhattiprolu
     [not found]         ` <20081224212426.GD13502-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-12-24 22:03           ` Oleg Nesterov
2008-12-24 22:03             ` Oleg Nesterov
2008-12-27 20:38             ` Sukadev Bhattiprolu
2008-12-24 11:51 ` [RFC][PATCH 4/7][v4] Protect cinit from unblocked SIG_DFL signals Sukadev Bhattiprolu
2008-12-24 11:52 ` [RFC][PATCH 5/7][v4] Protect cinit from blocked fatal signals Sukadev Bhattiprolu
2008-12-24 16:09   ` Oleg Nesterov
2008-12-24 21:25     ` Sukadev Bhattiprolu
2008-12-31  0:04     ` Roland McGrath
2009-01-05 12:24       ` Oleg Nesterov
2008-12-24 11:53 ` [RFC][PATCH 6/7][v4] SI_USER: Masquerade si_pid when crossing pid ns boundary Sukadev Bhattiprolu
2008-12-24 15:43   ` Oleg Nesterov
2008-12-24 16:18     ` Oleg Nesterov
2008-12-24 21:08     ` Sukadev Bhattiprolu
2008-12-24 11:53 ` [RFC][PATCH 7/7][v4] SI_TKILL: " Sukadev Bhattiprolu
2008-12-24 15:55   ` Oleg Nesterov
2008-12-24 21:04     ` Sukadev Bhattiprolu
2008-12-24 21:34       ` 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=20081224115124.GC8020@us.ibm.com \
    --to=sukadev@linux.vnet.ibm.com \
    --cc=bastian@waldi.eu.org \
    --cc=containers@lists.osdl.org \
    --cc=daniel@hozac.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=roland@redhat.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.