From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752749Ab1HLQaO (ORCPT ); Fri, 12 Aug 2011 12:30:14 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:57276 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752110Ab1HLQ3Y (ORCPT ); Fri, 12 Aug 2011 12:29:24 -0400 Date: Fri, 12 Aug 2011 11:29:08 -0500 From: Serge Hallyn To: Daniel Lezcano Cc: akpm@linux-foundation.org, containers@lists.linux-foundation.org, bonbons@linux-vserver.org, oleg@tv-sign.ru, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] Notify container-init parent a 'reboot' occured Message-ID: <20110812162908.GA9304@peqn> References: <1313094241-3674-1-git-send-email-daniel.lezcano@free.fr> <1313094241-3674-3-git-send-email-daniel.lezcano@free.fr> <20110811210951.GA17349@peqn> <4E444A04.3070403@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E444A04.3070403@free.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Daniel Lezcano (daniel.lezcano@free.fr): ... > > Doesn't this mean that an unprivileged task in a container can shut > > down the container? > > Ha ha ! Right, good catch :) > > Yes, rethinking about it, we can do what initially proposed Bruno by > just preventing to reboot when we are not in the init_pid_ns. Actually, > the sys_reboot occurs after the services shutdown and "kill -1 SIGTERM" > and "kill -1 SIGKILL", and would not make sense to do that in a child > pid namespace, except if we are in a container where we don't want to > reboot :) > > So IMO, it is safe to do: > > if (!ns_capable(current_pid_ns()->user_ns, CAP_SYS_BOOT)) > return -EPERM; > > if (pid_ns != &init_pid_ns) > return pid_namespace_reboot(pid_ns, cmd, buffer); So I don't know if you want to prepend http://kernel.ubuntu.com/git?p=serge/linux-syslogns.git;a=commit;h=63556e9a39bcd75ec4a88333425800905013c73e to your patchset, or just check nsown_capable(CAP_SYS_BOOT) for now, but as soon as you resend with that I'll happily, nay, ecstatically ack. thanks, -serge