[lxc-users] Running docker inside unprivileged LXC containers

[Akshay Karle]

Understood. I think I can work on a pull request for docker to create
devices only if devices cgroup and uid_map is present and has the 0 0
4294967295 value. If not I can just skip creation of devices and continue. They
shouldn't have a problem with that. I will let you know if I once I
make the changes. Hopefully very soon we should be able to run docker
inside lxc. Thanks a lot for all the help!

On Wed, Jun 17, 2015 at 12:22 PM Serge Hallyn <serge.hallyn at ubuntu.com>
wrote:

> Quoting Akshay Karle (akshay.a.karle at gmail.com):
> > Hey,
> >
> > I'm running docker inside the unprivileged lxc container. So when I
> checked
> > /proc/self/uid_map inside the lxc container it shows a different range of
> > uids:
> >          0     100000      65536
> > which I think are the default values, right?
>
> Yeah, and these mean that you cannot create devices.
>
> > So are there no other ways to
> > detect what all devices can be created in a container or if they can be
> > created at all?
>
> You cannot create any devices at all if your uid_map does not say 0 0
> 4294967295
>
> So I'm suggesting that you not create devices if *either* uid_map does
> *not* read 0 0 4294967295, *or* the devices are not granted in your
> devices cgroup.  (Btw a generic small command line tool to check that
> might be generally useful to many people)  Is there any reason why
> that wouldn't work for you?
>
> > I do see an environment variable in the lxc container called 'container'
> > set to 'lxc'. I could potentially use this to determine whether or not to
> > create devices when starting the docker container but will use this as
> the
> > last resort as I'm not sure if docker folks would accept that pull
> request.
> >
> > On Tue, Jun 16, 2015 at 4:25 PM Serge Hallyn <serge.hallyn at ubuntu.com>
> > wrote:
> >
> > > Hi,
> > >
> > > the inability to create devices in an unprivileged container actually
> > > is unrelated to the devices cgroup.  It's probably best to just check
> > > /proc/self/uid_map.  If it reads
> > >
> > >          0          0 4294967295
> > >
> > > then you are (most likely) in the initial user namespace.  You won't
> > > be able to create devices then even if devices cgroup is not in use.
> > >
> > > So I guess you'll probably want to check for both.
> > >
> > > -serge
> > >
> > > Quoting Akshay Karle (akshay.a.karle at gmail.com):
> > > > Hi,
> > > >
> > > > After the comments here, I had a look closer look at the docker
> code. The
> > > > problem was that it would always try to create some default devices
> > > > <
> > >
> https://github.com/docker/libcontainer/blob/master/configs/device_defaults.go
> > > >
> > > > without
> > > > it checking if it had the permissions to do so. For now, I've
> created a
> > > > fork of docker and added a fix to create the devices only if the
> devices
> > > > cgroup is present
> > > > <
> > >
> https://github.com/akshaykarle/docker/commit/0299d2c2084d7f42e7c2c433fca7f5ab3066d2be
> > > >.
> > > > This seems to work and I'm now able to run docker inside
> unprivileged LXC
> > > > containers.
> > > >
> > > > But I don't know if just checking for the devices cgroup mountpoint
> is
> > > the
> > > > right fix. I feel the right way would be to create only those devices
> > > that
> > > > are allowed by lxc.cgroup.devices.allow, but I don't know how I can
> check
> > > > the devices enabled in the unprivileged lxc container itself. Any
> way to
> > > do
> > > > so?
> > > >
> > > > On Mon, Jun 15, 2015 at 2:42 PM Serge Hallyn <
> serge.hallyn at ubuntu.com>
> > > > wrote:
> > > >
> > > > > Quoting Stewart Brodie (sbrodie at espial.com):
> > > > > > Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > > > > >
> > > > > > > Quoting Stewart Brodie (sbrodie at espial.com):
> > > > >
> > > > > > > > However, another far neater way of doing this could be to
> use the
> > > > > > > > freezer instead.  Just give lxc-start a new command-line
> option
> > > to
> > > > > start
> > > > > > > > the container *but* crucially, leave it frozen when lxc-start
> > > exits.
> > > > > > > > The caller can then just do lxc-start, lxc-device,
> lxc-unfreeze.
> > > > > >
> > > > > > > > [can you run lxc-device on a frozen container?]
> > > > > >
> > > > > > For future reference, this does indeed work.  I like the idea,
> > > because it
> > > > > > would allow all sorts of fettling to go on with the new container
> > > from
> > > > > the
> > > > > > host side before it really starts executing.
> > > > >
> > > > > fwiw I'm not opposed to this if someone wants to code it up.
> Basically
> > > > > right before exec(2)ing /sbin/init, the task would freeze itself.
> > > > > _______________________________________________
> > > > > lxc-users mailing list
> > > > > lxc-users at lists.linuxcontainers.org
> > > > > http://lists.linuxcontainers.org/listinfo/lxc-users
> > >
> > > > _______________________________________________
> > > > lxc-users mailing list
> > > > lxc-users at lists.linuxcontainers.org
> > > > http://lists.linuxcontainers.org/listinfo/lxc-users
> > >
> > > _______________________________________________
> > > lxc-users mailing list
> > > lxc-users at lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-users
>
> > _______________________________________________
> > lxc-users mailing list
> > lxc-users at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20150618/fab76f17/attachment.html>