From: Bastian Blank <bastian@waldi.eu.org>
To: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: oleg@redhat.com, ebiederm@xmission.com, roland@redhat.com,
containers@lists.osdl.org, linux-kernel@vger.kernel.org,
xemul@openvz.org
Subject: Re: [RFC][PATCH 3/5] Determine if sender is from ancestor ns
Date: Tue, 2 Dec 2008 12:48:33 +0100 [thread overview]
Message-ID: <20081202114833.GA1132@wavehammer.waldi.eu.org> (raw)
In-Reply-To: <20081201201506.GB12493@us.ibm.com>
On Mon, Dec 01, 2008 at 12:15:06PM -0800, Sukadev Bhattiprolu wrote:
> Bastian Blank [bastian@waldi.eu.org] wrote:
> | If I see this correctly this information is already covered in si_code
> | with SI_USER and SI_TKILL. SI_KERNEL is used for explicit kernel
> | generated signals.
>
> Yes, but si_code from sys_rt_sigqueueinfo() cannot be trusted.
sys_rt_sigqueueinfo disallows setting si_code to any value which
describes kernel signals from userspace. So using SI_FROMUSER should be
sufficient.
> IOW, we need to find the namespace of the sender only if the sender is
> a user process. If signal is originating from kernel, safely checking
> namespace becomes more complex.
Where does this imply checking sender for kernel generated signals?
> Yes, current approach is somewhat hacky. We tried other approaches
> before and they were either intrusive or required non-trivial changes
> to semantics of signals to global init or both.
Message-IDs?
> | > +static inline int siginfo_from_ancestor_ns(struct task_struct *t,
> | > + siginfo_t *info)
> | > +{
> | > + if (!is_si_special(info) && (info->si_signo & SIG_FROM_USER)) {
> | > + /* if t can't see us we are from parent ns */
> | What?
> I assume your question is about the comment :-)
Yes.
> Yes, a process can see all its descendants and processes in descendant
> namespaces. But it can only see its ancestors upto the most recent
> CLONE_NEWPID. (kind of like chroot in filesystems). So if receiver
> can't see sender, sender must be an ancestor.
Please add a complete comment to the function which describes the
function. And don't us "it" for not defined entities.
Bastian
--
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3
next prev parent reply other threads:[~2008-12-02 11:48 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 3:42 [RFC][PATCH 0/5] Container init signal semantics Sukadev Bhattiprolu
2008-11-26 3:44 ` [RFC][PATCH 1/5] pid: Implement ns_of_pid Sukadev Bhattiprolu
2008-11-26 3:44 ` Sukadev Bhattiprolu
2008-11-27 1:19 ` Bastian Blank
2008-12-01 20:24 ` Sukadev Bhattiprolu
2008-12-02 11:58 ` Bastian Blank
2008-12-02 22:12 ` Sukadev Bhattiprolu
2008-12-03 0:34 ` Valdis.Kletnieks
2008-11-26 3:45 ` [RFC][PATCH 2/5] pid: Generalize task_active_pid_ns Sukadev Bhattiprolu
2008-11-26 3:45 ` Sukadev Bhattiprolu
2008-11-27 1:17 ` Bastian Blank
2008-11-27 21:19 ` Greg Kurz
2008-12-01 21:15 ` Sukadev Bhattiprolu
2008-12-02 11:57 ` Bastian Blank
2008-12-03 7:41 ` Sukadev Bhattiprolu
2008-12-03 7:41 ` Sukadev Bhattiprolu
2008-12-04 12:58 ` Bastian Blank
2008-11-27 13:09 ` Nadia Derbey
2008-12-01 20:38 ` Sukadev Bhattiprolu
2008-11-26 3:46 ` [RFC][PATCH 3/5] Determine if sender is from ancestor ns Sukadev Bhattiprolu
2008-11-26 3:46 ` Sukadev Bhattiprolu
[not found] ` <20081126034611.GC23238-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-11-27 1:01 ` Bastian Blank
2008-11-27 1:01 ` Bastian Blank
2008-12-01 20:15 ` Sukadev Bhattiprolu
2008-12-02 11:48 ` Bastian Blank [this message]
2008-12-02 19:59 ` Sukadev Bhattiprolu
2008-12-04 12:45 ` [RFC][PATCH 3/5] Determine if sender is from ancestor ns+ Bastian Blank
2008-12-04 1:06 ` [RFC][PATCH 3/5] Determine if sender is from ancestor ns Roland McGrath
2008-12-04 1:06 ` Roland McGrath
2008-12-09 3:22 ` Sukadev Bhattiprolu
2008-12-02 3:07 ` Roland McGrath
2008-11-26 3:46 ` [RFC][PATCH 4/5] Protect cinit from fatal signals Sukadev Bhattiprolu
2008-11-26 3:46 ` Sukadev Bhattiprolu
2008-11-27 1:07 ` Bastian Blank
2008-12-01 20:21 ` Sukadev Bhattiprolu
2008-12-02 12:06 ` Bastian Blank
2008-12-02 20:51 ` Sukadev Bhattiprolu
2008-12-04 12:52 ` Bastian Blank
2008-12-04 18:58 ` Sukadev Bhattiprolu
2008-11-26 3:46 ` [RFC][PATCH 5/5] Clear si_pid for signal from ancestor ns Sukadev Bhattiprolu
2008-11-26 3:46 ` 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=20081202114833.GA1132@wavehammer.waldi.eu.org \
--to=bastian@waldi.eu.org \
--cc=containers@lists.osdl.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--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.