[lxc-users] Failure to start a container with 'lxc.seccomp' option set

Nels Nelson nels.n.nelson at gmail.com
Mon Apr 28 18:39:39 UTC 2014


On Mon, Apr 28, 2014 at 1:30 PM, Serge Hallyn <serge.hallyn at ubuntu.com>wrote:

> Try doing
>
> sed -i 's/mknod/mknod errno 0/' /tmp/blacklist
>
> and see if it now loads.  (errno 0 means it won't allow the mknod,
> but will return success as though it had worked)
>

This does in fact allow the container to start properly!



> > I suppose my question is now: Is LXC somehow actually applying the
> seccomp
> > restrictions to the container resources prior to init?  And if so, why?
>
> Prior to init, yes, but very close to the end.  In fact right before
> we run the start hooks.  Since the start hooks come from the container
> rootfs, we have to run them under seccomp.  After that we close the
> sigfd (so close has to be allowed), but that's about it.
>

This is very interesting.  I will try experimenting about with a variety of
syscall
black-lists to see what sort of proper usefulness I can obtain with seccomp
syscall limiting while still allowing the init process to complete, and
allow
user attachment to to the lxc instance.

Thanks again, Serge!

Cheers,
-Nels
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140428/4fccbc50/attachment.html>


More information about the lxc-users mailing list