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