<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 28, 2014 at 1:30 PM, Serge Hallyn <span dir="ltr"><<a href="mailto:serge.hallyn@ubuntu.com" target="_blank">serge.hallyn@ubuntu.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Try doing<br></div>
<br>
sed -i 's/mknod/mknod errno 0/' /tmp/blacklist<br>
<br>
and see if it now loads.  (errno 0 means it won't allow the mknod,<br>
but will return success as though it had worked)<br></blockquote><div><br></div><div>This does in fact allow the container to start properly!</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="">> I suppose my question is now: Is LXC somehow actually applying the seccomp<br>
> restrictions to the container resources prior to init?  And if so, why?<br>
<br>
</div>Prior to init, yes, but very close to the end.  In fact right before<br>
we run the start hooks.  Since the start hooks come from the container<br>
rootfs, we have to run them under seccomp.  After that we close the<br>
sigfd (so close has to be allowed), but that's about it.<br></blockquote><div><br></div><div>This is very interesting.  I will try experimenting about with a variety of syscall</div><div>black-lists to see what sort of proper usefulness I can obtain with seccomp</div>
<div>syscall limiting while still allowing the init process to complete, and allow</div><div>user attachment to to the lxc instance.</div><div><br></div><div>Thanks again, Serge!</div><div><br></div><div>Cheers,</div><div>
-Nels</div><div><br></div></div></div></div>