Last week we held an irc meeting to talk about user namespaces as they relate to lxc containers. The IRC log is posted at https://wiki.ubuntu.com/LxcUsernsIrcChat .
I had two goals for this meeting. The first was to make sure that lxc developers were familiar with user namespaces, so that as new patches started rolling in to accomodate user namespaces, more people might be inclined to review them – and spot my silly errors. The other was to discuss some design issues in the lxc code.
I began with some background on user namespaces, their design, motivation, and current status, topped off by a little demo on ec2. Then we proceeded to discuss future needed changes.
There are two terrific advantages to using user namespaces.
The first is that host resources are not subject to privilege in the container. That is, root in the container is not root on the host, and a fully privileged task in a container cannot exert any privilege over any resources which are not owned by the container. This advantage is fully realized right now when using lxc with a custom kernel, as per http://s3hh.wordpress.com/2012/10/31/full-ubuntu-container-confined-in-a-user-namespace. By the time raring is released, I hope for the stock raring lxc, with a custom kernel from ppa:ubuntu-lxc/kernels, to be usable in place of my personal ppa.
The second advantage of user namespaces is that they will allow unprivileged users to create and use containers. There are little things which will require privilege – like mapping userids into the container, and hooking the container’s network interface somehow into the host. Each of those can be enabled by small privileged helpers and configured in advance (and generically). So that, by 14.04 LTS, an unprivileged user should be able to safely, out of the box, do
lxc-create -t ubuntu -n r1
lxc-start -n r1
This should also be tremendously helpful for safer usage of juju with local provider.
The steps needed (or, at least, hopefully most of them) to get to that point are discussed in the meeting log above.