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

[Serge Hallyn]

Quoting Nels Nelson (nels.n.nelson at gmail.com):
> 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!

Drat.  just to make sure, you don't have any start hooks defined do you?
What distro/release is the guest running?  My guess is that init is
running mknod, and immediately getting killed.

> > > 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!

Np, good luck.  Please let us know what you end up with.

-serge