From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932863AbaJUTDF (ORCPT ); Tue, 21 Oct 2014 15:03:05 -0400 Received: from mail-lb0-f172.google.com ([209.85.217.172]:60213 "EHLO mail-lb0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932367AbaJUTDB (ORCPT ); Tue, 21 Oct 2014 15:03:01 -0400 MIME-Version: 1.0 In-Reply-To: References: <1413235430-22944-1-git-send-email-adityakali@google.com> <1413235430-22944-8-git-send-email-adityakali@google.com> <20141016211236.GA4308@mail.hallyn.com> <20141016214710.GA4759@mail.hallyn.com> <87iojgmy3o.fsf@x220.int.ebiederm.org> <44072106-c0f3-46b8-b2b5-9b1cbd1b7d88@email.android.com> <87zjcq10ya.fsf@x220.int.ebiederm.org> <87lhoayo59.fsf@x220.int.ebiederm.org> From: Andy Lutomirski Date: Tue, 21 Oct 2014 12:02:37 -0700 Message-ID: Subject: Re: [PATCHv1 7/8] cgroup: cgroup namespace setns support To: Aditya Kali Cc: "Eric W. Biederman" , "Serge E. Hallyn" , Linux API , Linux Containers , Serge Hallyn , "linux-kernel@vger.kernel.org" , Tejun Heo , cgroups@vger.kernel.org, Ingo Molnar Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 21, 2014 at 11:49 AM, Aditya Kali wrote: > On Mon, Oct 20, 2014 at 10:49 PM, Andy Lutomirski wrote: >> On Mon, Oct 20, 2014 at 10:42 PM, Eric W. Biederman >> wrote: >>> >>> I do wonder if we think of this as chcgrouproot if there is a simpler >>> implementation. >> >> Could be. I'll defer to Aditya for that one. >> > > More than chcgrouproot, its probably closer to pivot_cgroup_root. In > addition to restricting the process to a cgroup-root, new processes > entering the container should also be implicitly contained within the > cgroup-root of that container. Why? Concretely, why should this be in the kernel namespace code instead of in userspace? > Implementing pivot_cgroup_root would > probably involve overloading mount-namespace to now understand cgroup > filesystem too. I did attempt combining cgroupns-root with mntns > earlier (not via a new syscall though), but came to the conclusion > that its just simpler to have a separate cgroup namespace and get > clear semantics. One of the issues was that implicitly changing cgroup > on setns to mntns seemed like a huge undesirable side-effect. > > About pinning: I really feel that it should be OK to pin processes > within cgroupns-root. I think thats one of the most important feature > of cgroup-namespace since its most common usecase is to containerize > un-trusted processes - processes that, for their entire lifetime, need > to remain inside their container. So don't let them out. None of the other namespaces have this kind of constraint: - If you're in a mntns, you can still use fds from outside. - If you're in a netns, you can still use sockets from outside the namespace. - If you're in an ipcns, you can still use ipc handles from outside. etc. > And with explicit permission from > cgroup subsystem (something like cgroup.may_unshare as you had > suggested previously), we can make sure that unprivileged processes > cannot pin themselves. Also, maintaining this invariant (your current > cgroup is always under your cgroupns-root) keeps the code and the > semantics simple. I actually think it makes the semantics more complex. The less policy you stick in the kernel, the easier it is to understand the impact of that policy. > > If we ditch the pinning requirement and allow the containarized > process to move outside of its cgroupns-root, we will have to address > atleast the following: > * what does its /proc/self/cgroup (and /proc//cgroup in general) > look like? We might need to just not show anything in > /proc//cgroup in such case (for default hierarchy). The process should see the cgroup path relative to its cgroup ns. Whether this requires a new /proc mount or happens automatically is an open question. (I *hate* procfs for reasons like this.) > * how should future setns() and unshare() by such process behave? Open question. > * 'mount -t cgroup cgroup ' by such a process will yield unexpected result You could disallow that and instead require 'mount -t cgroup -o cgrouproot=. cgroup mnt' where '.' will be resolved at mount time relative to the caller's cgroupns. > * container will not remain migratable Why not? > * added code complexity to handle above scenarios > > I understand that having process pinned to a cgroup hierarchy might > seem inconvenient. But even today (without cgroup namespaces), moving > a task from one cgroup to another can fail for reasons outside of > control of the task attempting the move (even if its privileged). So > the userspace should already handle this scenario. I feel its not > worth to add complexity in the kernel for this. --Andy