From: Aleksa Sarai <asarai@suse.de>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
David Howells <dhowells@redhat.com>,
trondmy@primarydata.com
Cc: mszeredi@redhat.com, linux-nfs@vger.kernel.org,
jlayton@redhat.com,
Linux Containers <containers@lists.linux-foundation.org>,
linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org,
ebiederm@xmission.com
Subject: Re: [RFC][PATCH 0/9] Make containers kernel objects
Date: Tue, 23 May 2017 03:14:00 +1000 [thread overview]
Message-ID: <f167feeb-e653-12e3-eec8-24162f7f7c07@suse.de> (raw)
In-Reply-To: <1495472039.2757.19.camel@HansenPartnership.com>
>> 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/
next prev parent reply other threads:[~2017-05-22 17:14 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 16:22 [RFC][PATCH 0/9] Make containers kernel objects David Howells
2017-05-22 16:22 ` [PATCH 1/9] containers: Rename linux/container.h to linux/container_dev.h David Howells
2017-05-22 16:22 ` [PATCH 2/9] Implement containers as kernel objects David Howells
2017-08-14 5:47 ` Richard Guy Briggs
2017-08-16 22:21 ` Paul Moore
2017-08-18 8:03 ` Richard Guy Briggs
2017-09-06 14:03 ` Serge E. Hallyn
2017-09-14 5:47 ` Richard Guy Briggs
2017-09-08 20:02 ` Paul Moore
2017-05-22 16:22 ` [PATCH 3/9] Provide /proc/containers David Howells
2017-05-22 16:22 ` [PATCH 4/9] Allow processes to be forked and upcalled into a container David Howells
2017-05-22 16:23 ` [PATCH 5/9] Open a socket inside " David Howells
2017-05-22 16:23 ` [PATCH 6/9] Allow fs syscall dfd arguments to take a container fd David Howells
2017-05-22 16:23 ` [PATCH 7/9] Make fsopen() able to initiate mounting into a container David Howells
2017-05-22 16:23 ` [PATCH 8/9] Honour CONTAINER_NEW_EMPTY_FS_NS David Howells
2017-05-22 16:23 ` [PATCH 9/9] Sample program for driving container objects David Howells
2017-05-22 16:53 ` [RFC][PATCH 0/9] Make containers kernel objects James Bottomley
2017-05-22 17:14 ` Aleksa Sarai [this message]
2017-05-22 17:27 ` Jessica Frazelle
2017-05-22 18:34 ` Jeff Layton
2017-05-22 19:21 ` James Bottomley
2017-05-22 22:14 ` Jeff Layton
2017-05-23 10:35 ` Ian Kent
2017-05-23 9:38 ` Ian Kent
2017-05-23 14:53 ` David Howells
2017-05-23 14:56 ` Eric W. Biederman
2017-05-23 15:14 ` David Howells
2017-05-23 15:17 ` Eric W. Biederman
2017-05-23 15:44 ` James Bottomley
2017-05-23 16:36 ` David Howells
2017-05-24 8:26 ` Eric W. Biederman
2017-05-24 9:16 ` Ian Kent
2017-05-22 17:11 ` Jessica Frazelle
2017-05-22 19:04 ` Eric W. Biederman
2017-05-22 22:22 ` Jeff Layton
2017-05-23 12:54 ` Eric W. Biederman
2017-05-23 14:27 ` Jeff Layton
2017-05-23 14:30 ` Djalal Harouni
2017-05-23 14:54 ` Colin Walters
2017-05-23 15:31 ` Jeff Layton
2017-05-23 15:35 ` Colin Walters
2017-05-23 15:30 ` David Howells
2017-05-23 14:23 ` Djalal Harouni
2017-05-27 17:45 ` Trond Myklebust
2017-05-27 19:10 ` James Bottomley
2017-05-23 10:09 ` Ian Kent
2017-05-23 13:52 ` David Howells
2017-05-23 15:02 ` James Bottomley
2017-05-23 15:23 ` Eric W. Biederman
2017-05-23 15:12 ` David Howells
2017-05-23 15:33 ` Eric W. Biederman
2017-05-23 16:13 ` David Howells
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=f167feeb-e653-12e3-eec8-24162f7f7c07@suse.de \
--to=asarai@suse.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=cgroups@vger.kernel.org \
--cc=containers@lists.linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=jlayton@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mszeredi@redhat.com \
--cc=trondmy@primarydata.com \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).