<div dir="ltr">Hey,<div><br></div><div>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:</div><div><div>         0     100000      65536</div><div>which I think are the default values, right? 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?</div><div><br></div><div>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.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 16, 2015 at 4:25 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">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>
> <<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>
> 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>
> <<a href="https://github.com/akshaykarle/docker/commit/0299d2c2084d7f42e7c2c433fca7f5ab3066d2be" rel="noreferrer" target="_blank">https://github.com/akshaykarle/docker/commit/0299d2c2084d7f42e7c2c433fca7f5ab3066d2be</a>>.<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 the<br>
> right fix. I feel the right way would be to create only those devices 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 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 to<br>
> > start<br>
> > > > > the container *but* crucially, leave it frozen when lxc-start 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, because it<br>
> > > would allow all sorts of fettling to go on with the new container 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></blockquote></div></div></div>