All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@free.fr>
To: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: containers@lists.linux-foundation.org,
	LXC@d06av03.portsmouth.uk.ibm.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Development <Lxc-devel@lists.sourceforge.net>
Subject: Re: [lxc-devel] [RFC] catching sys_reboot syscall
Date: Thu, 11 Aug 2011 20:10:20 +0200	[thread overview]
Message-ID: <4E441B0C.4060707@free.fr> (raw)
In-Reply-To: <20110811190456.77ff9280@neptune.home>

On 08/11/2011 07:04 PM, Bruno Prémont wrote:
> On Thu, 11 August 2011 Daniel Lezcano <daniel.lezcano@free.fr> wrote:
>> On 08/11/2011 06:30 PM, Bruno Prémont wrote:
>>> On Wed, 10 August 2011 Daniel Lezcano <daniel.lezcano@free.fr> wrote:
>>>> On 08/10/2011 10:10 PM, Bruno Prémont wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> [I'm adding containers ml as we had a discussion there some time ago
>>>>>  for this feature]
>>>> [ ... ]
>>>>
>>>>>> +    if (cmd == LINUX_REBOOT_CMD_RESTART2)
>>>>>> +        if (strncpy_from_user(&buffer[0], arg, sizeof(buffer) - 1) < 0)
>>>>>> +            return -EFAULT;
>>>>>> +
>>>>>> +    /* If we are not in the initial pid namespace, we send a signal
>>>>>> +     * to the parent of this init pid namespace, notifying a shutdown
>>>>>> +     * occured */
>>>>>> +    if (pid_ns != &init_pid_ns)
>>>>>> +        pid_namespace_reboot(pid_ns, cmd, buffer);
>>>>> Should there be a return here?
>>>>> Or does pid_namespace_reboot() never return by submitting signal to
>>>>> parent?
>>>> Yes, it does not return a value, like 'do_notify_parent_cldstop'
>>> So execution flow continues reaching the whole "host reboot code"?
>>>
>>> That's not so good as it then prevents using CAP_SYS_BOOT inside PID namespace
>>> to limit access to rebooting the container from inside as giving a process
>>> inside container CAP_SYS_BOOT would cause host to reboot (and when not given
>>> process inside container would get -EPERM in all cases).
>>>
>>> Wouldn't the following be better?:
>>> ...
>>> +
>>> +    /* We only trust the superuser with rebooting the system. */
>>> +    if (!capable(CAP_SYS_BOOT))
>>> +        return -EPERM;
>>> +
>>> +    /* If we are not in the initial pid namespace, we send a signal
>>> +     * to the parent of this init pid namespace, notifying a shutdown
>>> +     * occured */
>>> +    if (pid_ns != &init_pid_ns) {
>>> +        pid_namespace_reboot(pid_ns, cmd, buffer);
>>> +        return 0;
>>> +    }
>>> +
>>>      mutex_lock(&reboot_mutex);
>>>      switch (cmd) {
>>> ...
>>>
>>>
>>> If I misunderstood, please correct me.
>>
>> Yep, this is what I did at the beginning but I realized I was closing
>> the door for future applications using the pid namespaces. The pid
>> namespace could be used by another kind of application, not a container,
>> running some administrative tasks so they may want to shutdown the host
>> from a different pid namespace.
>>
>> For this reason, to prevent this execution flow, the container has to
>> drop the CAP_SYS_BOOT in addition of taking care of the SIGCHLD signal
>> with CLDREBOOT.
> 
> Ok, though for later source code readers to know adding/extending comment
> would be nice.
> Maybe something like
> 
> +    /* If we are not in the initial pid namespace, we send a signal
> +     * to the parent of this init pid namespace, notifying a shutdown
> +     * occured
> +     * NOTE: if process has CAP_SYS_BOOT it will additionally have the
> +     * same effect as if it was not namespaced */
> 
> 
> How would all of this integrate with the ongoing work on user namespaces?
> Maybe that one should later be the differentiator for who may or may not
> trigger the host reboot.

I think if you are in a different user namespace than the init one, the
process won't be able to reboot.
I talked with Serge about that and he should execute the
pid_namespace_reboot if it is 'ns_capable' of rebooting the host.

But I think that does not collide after all.


> In addition sending the signal to parent process seems moot as chances are
> that parent process will never have the opportunity to see the signal when
> the host is being rebooted.

Right.

> Then a construct like the following would give a better hint to the reader:
> ...
> +
> +    /* We only trust the superuser with rebooting the system. */
> +    if (!capable(CAP_SYS_BOOT)) {
> +        /* If we are not in the initial pid namespace, we send a signal
> +         * to the parent of this init pid namespace, notifying a shutdown
> +         * occured */
> +        if (pid_ns != &init_pid_ns)
> +            pid_namespace_reboot(pid_ns, cmd, buffer);
> +
> +        return -EPERM;
> +    }

Ok, let me respin the patchset and change that. I will submit the patch
to akpm and lkml. Let's see what they think about this approach.

Thanks
  -- Daniel

  reply	other threads:[~2011-08-11 18:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-08 21:14 [RFC] catching sys_reboot syscall Daniel Lezcano
     [not found] ` <4E4051A0.8030009-GANU6spQydw@public.gmane.org>
2011-08-10 20:10   ` Bruno Prémont
2011-08-10 20:10     ` Bruno Prémont
2011-08-10 20:49     ` Daniel Lezcano
2011-08-11 16:30       ` Bruno Prémont
     [not found]         ` <20110811183027.49275b2d-hY15tx4IgV39zxVx7UNMDg@public.gmane.org>
2011-08-11 16:49           ` Daniel Lezcano
2011-08-11 16:49         ` Daniel Lezcano
2011-08-11 17:04           ` Bruno Prémont
2011-08-11 18:10             ` Daniel Lezcano [this message]
     [not found]             ` <20110811190456.77ff9280-hY15tx4IgV39zxVx7UNMDg@public.gmane.org>
2011-08-11 18:10               ` [lxc-devel] " Daniel Lezcano
2011-08-11 18:10               ` Serge Hallyn
2011-08-11 18:10             ` Serge Hallyn
2011-08-11 18:40               ` [PATCH] add pid->user_ns Serge Hallyn
2011-08-11 18:40               ` Serge Hallyn
     [not found]           ` <4E44082F.6040606-GANU6spQydw@public.gmane.org>
2011-08-11 17:04             ` [RFC] catching sys_reboot syscall Bruno Prémont
     [not found]       ` <4E42EEE3.9050608-GANU6spQydw@public.gmane.org>
2011-08-11 16:30         ` Bruno Prémont
     [not found]     ` <20110810221028.2e0c8590-hY15tx4IgV39zxVx7UNMDg@public.gmane.org>
2011-08-10 20:49       ` Daniel Lezcano
2011-08-20 11:03 ` Pavel Machek

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=4E441B0C.4060707@free.fr \
    --to=daniel.lezcano@free.fr \
    --cc=LXC@d06av03.portsmouth.uk.ibm.com \
    --cc=Lxc-devel@lists.sourceforge.net \
    --cc=bonbons@linux-vserver.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.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.