From: Oleg Nesterov <oleg@redhat.com>
To: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: ebiederm@xmission.com, roland@redhat.com, bastian@waldi.eu.org,
daniel@hozac.com, xemul@openvz.org, containers@lists.osdl.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 3/7][v4] Define siginfo_from_ancestor_ns()
Date: Wed, 24 Dec 2008 17:28:23 +0100 [thread overview]
Message-ID: <20081224162823.GE11593@redhat.com> (raw)
In-Reply-To: <20081224115124.GC8020@us.ibm.com>
On 12/24, Sukadev Bhattiprolu wrote:
>
> +#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;
> +}
Small nit... siginfo_from_user() is only called by siginfo_from_ancestor_ns().
The first helper depends on CONFIG_PID_NS, the second is not. A bit strange.
Isn't it cleaner to do
#ifdef CONFIG_PID_NS
static inline int siginfo_from_user(siginfo_t *info)
{
...
}
static inline int siginfo_from_ancestor_ns(...)
{
...
}
#else
static inline int siginfo_from_ancestor_ns(...)
{
return 0;
}
#endif
?
> +#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);
Hmm... why do you want this? The user-space can use any si_code >= 0,
why should we uglify the code?
And, SI_ASYNCIO only matters when we send the signal to the subnamespace,
and in that case we will probably mangle .si_pid. So why don't we warn
when .si_code == SI_USER?
Oleg.
next prev parent reply other threads:[~2008-12-24 16:28 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 ` [RFC][PATCH 3/7][v4] Define siginfo_from_ancestor_ns() Sukadev Bhattiprolu
2008-12-24 16:28 ` Oleg Nesterov [this message]
[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=20081224162823.GE11593@redhat.com \
--to=oleg@redhat.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=roland@redhat.com \
--cc=sukadev@linux.vnet.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.