From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934796AbdEVROY (ORCPT ); Mon, 22 May 2017 13:14:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:33693 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932968AbdEVROU (ORCPT ); Mon, 22 May 2017 13:14:20 -0400 Subject: Re: [RFC][PATCH 0/9] Make containers kernel objects To: James Bottomley , David Howells , trondmy@primarydata.com Cc: mszeredi@redhat.com, linux-nfs@vger.kernel.org, jlayton@redhat.com, Linux Containers , linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org, ebiederm@xmission.com References: <149547014649.10599.12025037906646164347.stgit@warthog.procyon.org.uk> <1495472039.2757.19.camel@HansenPartnership.com> From: Aleksa Sarai Message-ID: Date: Tue, 23 May 2017 03:14:00 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <1495472039.2757.19.camel@HansenPartnership.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> The reason I think this is necessary is that the kernel has no idea >> how to direct upcalls to what userspace considers to be a container - >> current Linux practice appears to make a "container" just an >> arbitrarily chosen junction of namespaces, control groups and files, >> which may be changed individually within the "container". Just want to point out that if the kernel APIs for containers massively change, then the OCI will have to completely rework how we describe containers (and so will all existing runtimes). Not to mention that while I don't like how hard it is (from a runtime perspective) to actually set up a container securely, there are undoubtedly benefits to having namespaces split out. The network namespace being separate means that in certain contexts you actually don't want to create a new network namespace when creating a container. I had some ideas about how you could implement bridging in userspace (as an unprivileged user, for rootless containers) but if you can't join namespaces individually then such a setup is not practically possible. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aleksa Sarai Subject: Re: [RFC][PATCH 0/9] Make containers kernel objects Date: Tue, 23 May 2017 03:14:00 +1000 Message-ID: References: <149547014649.10599.12025037906646164347.stgit@warthog.procyon.org.uk> <1495472039.2757.19.camel@HansenPartnership.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1495472039.2757.19.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> Content-Language: en-US Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: James Bottomley , David Howells , trondmy-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org Cc: mszeredi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Linux Containers , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org >> The reason I think this is necessary is that the kernel has no idea >> how to direct upcalls to what userspace considers to be a container - >> current Linux practice appears to make a "container" just an >> arbitrarily chosen junction of namespaces, control groups and files, >> which may be changed individually within the "container". Just want to point out that if the kernel APIs for containers massively change, then the OCI will have to completely rework how we describe containers (and so will all existing runtimes). Not to mention that while I don't like how hard it is (from a runtime perspective) to actually set up a container securely, there are undoubtedly benefits to having namespaces split out. The network namespace being separate means that in certain contexts you actually don't want to create a new network namespace when creating a container. I had some ideas about how you could implement bridging in userspace (as an unprivileged user, for rootless containers) but if you can't join namespaces individually then such a setup is not practically possible. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html