linux-kernel - Re: [PATCH 0/2] Send a SIGCHLD to the init's pid namespace parent when reboot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E524B73.3050704@free.fr>
Date:	Mon, 22 Aug 2011 14:28:35 +0200
From:	Daniel Lezcano <daniel.lezcano@...e.fr>
To:	Oleg Nesterov <oleg@...hat.com>
CC:	"Serge E. Hallyn" <serge@...lyn.com>, akpm@...ux-foundation.org,
	bonbons@...ux-vserver.org, containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Send a SIGCHLD to the init's pid namespace parent
 when reboot

On 08/19/2011 05:24 PM, Oleg Nesterov wrote:
> On 08/19, Daniel Lezcano wrote:
>> On 08/15/2011 04:47 PM, Oleg Nesterov wrote:
>>> 	- sys_reboot(cmd) does
>>>
>>> 		if (!global_namespace) {
>>> 			task_active_pid_ns(current)->reboot_cmd = cmd;
>>> 			sigkill_my_init();
>>> 		}
>> Hi Oleg,
>>
>> what would be your advice to get rid of from_ancestor_ns which prevent
>> the signal to be delivered to the init process ?
> Sure, a plain kill can't work. You can do force_sig_info(), this clears
> SIGNAL_UNKILLABLE.
>
> Hmm. But now I seem to recall we have other reasons to make the new
> sigkill_task() helper... We will see. Anyway, force_ should work afaics.

Thanks Oleg.

I wrote the patch by sending a signal to the init process of the pid
namespace using force_sig_info.
That works fine, thanks for the hint.

I am wondering what is the best way to transmit the reason of the reboot
to the parent of the container's init.

If we pass the reason to the exit_code of the init process, that will be
a bit weird as the process is signaled and did not exited  no ?
Furthermore, how to differentiate an application container (eg. a
script) exiting with an error with the same value of a reboot reason ?

Wouldn't make sense to let the user to specify a signal via prctl where
the si_code is filled with the reason ?

Without invoking the prctl, the init process is simply killed by the
kernel, otherwise we send the signal to the container's init.

>From userspace:

void sigreboot(int sig, siginfo_t *si, void *private)
{
    switch(si->si_code) {
       case LINUX_REBOOT_CMD_RESTART:
        reboot_container();
        break;

      case LINUX_REBOOT_CMD_HALT:
        halt_container();
        break;

     ...
    }
}

  struct sigaction sa = {
    .sa_sigaction = sigreboot,
    .sa_flags =  SA_SIGINFO;  
 }
 
 sigaction(SIGUSR1, &sa, NULL);

 prctl(PR_SIGREBOOT, SIGUSR1);

 -----

 and from the kernel (called from sys_reboot):

 int kill_pid_ns(struct pid_namespace *pid_ns, int reason)
{
        struct task_struct *tsk;
        struct siginfo info;

        if (pid_ns->notifier) {

                         info.si_signo = SIGKILL;
                         info.si_errno = 0;
                         info.si_code = reason;
                         info.si_pid = 0;
                         info.si_uid = 0;

                         return force_sig_info(notifier->sig, &info,
notifier->tsk);
        }

        write_lock_irq(&tasklist_lock);
        tsk = pid_ns->child_reaper;
        write_unlock_irq(&tasklist_lock);

        info.si_signo = SIGKILL;
        info.si_errno = 0;
        info.si_code = SI_KERNEL;
        info.si_pid = 0;
        info.si_uid = 0;

        return force_sig_info(SIGKILL, &info, tsk);
}

Roughly, assuming pid_ns->notifier is reseted when we reparent to the
init_pid_ns.init.

What do you think ?

Thanks
  -- Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/