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