Pavel Emelianov [EMAIL PROTECTED] wrote:
| When user send signal from (say) init namespace to any task in a sub
| namespace the siginfo struct must not carry the sender's pid value, as
| this value may refer to some task in the destination namespace and thus
| may confuse the application.
Also, do you prevent signals to the child reaper of a container from within
its container ? If so, can you show me where you handle it ? I can't
seem to find it.
And I guess you do allow signals to the child-reaper of a container from
its parent container.
|
| The consensus was to pretend in this case as if it is the kernel who
| sends the signal.
|
| The pid_ns_accessible() call is introduced to check this pid-to-ns
| accessibility.
|
| Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
|
| ---
|
| include/linux/pid.h | 10 ++++++++++
| kernel/signal.c | 34 ++++++++++++++++++++++++++++------
| 2 files changed, 38 insertions(+), 6 deletions(-)
|
| diff -upr linux-2.6.22-rc4-mm2.orig/include/linux/pid.h
linux-2.6.22-rc4-mm2-2/include/linux/pid.h
| --- linux-2.6.22-rc4-mm2.orig/include/linux/pid.h 2007-06-14
12:14:29.000000000 +0400
| +++ linux-2.6.22-rc4-mm2-2/include/linux/pid.h 2007-07-04
19:00:38.000000000 +0400
| @@ -83,6 +89,16 @@ extern void FASTCALL(detach_pid(struct t
| return nr;
| }
|
| +/*
| + * checks whether the pid actually lives in the namespace ns, i.e. it was
| + * created in this namespace or it was moved there.
| + */
| +
| +static inline int pid_ns_accessible(struct pid_namespace *ns, struct pid
*pid)
| +{
| + return pid->numbers[pid->level].ns == ns;
| +}
| +
| #define do_each_pid_task(pid, type, task) \
| do { \
| struct hlist_node *pos___; \
| diff -upr linux-2.6.22-rc4-mm2.orig/kernel/signal.c
linux-2.6.22-rc4-mm2-2/kernel/signal.c
| --- linux-2.6.22-rc4-mm2.orig/kernel/signal.c 2007-07-04 19:00:38.000000000
+0400
| +++ linux-2.6.22-rc4-mm2-2/kernel/signal.c 2007-07-04 19:00:38.000000000
+0400
| @@ -1124,13 +1124,31 @@ EXPORT_SYMBOL_GPL(kill_pid_info_as_uid);
| * is probably wrong. Should make it like BSD or SYSV.
| */
|
| -static int kill_something_info(int sig, struct siginfo *info, int pid)
| +static inline void masquerade_siginfo(struct pid_namespace *src_ns,
| + struct pid *tgt_pid, struct siginfo *info)
| +{
| + if (tgt_pid != NULL && !pid_ns_accessible(src_ns, tgt_pid)) {
| + /*
| + * current namespace is not seen from the taks we
| + * want to send the signal to, so pretend as if it
| + * is the kernel who does this to avoid pid messing
| + * by the target
| + */
| +
| + info->si_pid = 0;
| + info->si_code = SI_KERNEL;
| + }
| +}
| +
| +static int kill_something_info(int sig, struct siginfo *info, int pid_nr)
| {
| int ret;
| + struct pid *pid;
| +
| rcu_read_lock();
| - if (!pid) {
| + if (!pid_nr) {
| ret = kill_pgrp_info(sig, info, task_pgrp(current));
| - } else if (pid == -1) {
| + } else if (pid_nr == -1) {
| int retval = 0, count = 0;
| struct task_struct * p;
So what happens if we run "kill -s <sig> -1" from within a container ?
Do you terminate all processes in the system or just the process in
the container ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
