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.hal...@ubuntu.com> wrote: > Quoting Akshay Karle (akshay.a.ka...@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.hal...@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.ka...@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.hal...@ubuntu.com> > > > > wrote: > > > > > > > > > Quoting Stewart Brodie (sbro...@espial.com): > > > > > > Serge Hallyn <serge.hal...@ubuntu.com> wrote: > > > > > > > > > > > > > Quoting Stewart Brodie (sbro...@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@lists.linuxcontainers.org > > > > > http://lists.linuxcontainers.org/listinfo/lxc-users > > > > > > > _______________________________________________ > > > > lxc-users mailing list > > > > lxc-users@lists.linuxcontainers.org > > > > http://lists.linuxcontainers.org/listinfo/lxc-users > > > > > > _______________________________________________ > > > lxc-users mailing list > > > lxc-users@lists.linuxcontainers.org > > > http://lists.linuxcontainers.org/listinfo/lxc-users > > > _______________________________________________ > > lxc-users mailing list > > lxc-users@lists.linuxcontainers.org > > http://lists.linuxcontainers.org/listinfo/lxc-users > > _______________________________________________ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users
_______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users