[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