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
next prev parent reply other threads:[~2011-08-11 18:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-08 21:14 [RFC] catching sys_reboot syscall Daniel Lezcano
2011-08-10 20:10 ` Bruno Prémont
2011-08-10 20:49 ` Daniel Lezcano
2011-08-11 16:30 ` Bruno Prémont
2011-08-11 16:49 ` Daniel Lezcano
2011-08-11 17:04 ` Bruno Prémont
2011-08-11 18:10 ` Daniel Lezcano [this message]
2011-08-11 18:10 ` Serge Hallyn
2011-08-11 18:40 ` [PATCH] add pid->user_ns Serge Hallyn
2011-08-20 11:03 ` [RFC] catching sys_reboot syscall 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox