Quoting Stéphane Graber ([email protected]): > On Mon, Feb 17, 2014 at 05:16:51PM -0500, Stéphane Graber wrote: > > On Mon, Feb 17, 2014 at 02:05:10PM -0600, Serge Hallyn wrote: > > > If that is set, then if reading the policy failed, we continue > > > without trying to load seccomp. (If reading the policy > > > succeeded, then we do not ignore failure to load the policy; > > > we could consider doing that as well, however the goal here > > > is to have a generic container configuration work whether > > > the host has seccompv2 support or not) > > > > > > Signed-off-by: Serge Hallyn <[email protected]> > > > > Acked-by: Stéphane Graber <[email protected]> > > Actually, I'll wait a bit before pushing this, the code isn't > technically wrong (that I could see) but it's pretty confusing. > > The option isn't documented in lxc.container.conf.sgml and the behavior > of the option is a bit odd too. > > Let's take a lxc-clone example: > If .optional == 1 and .seccomp is invalid => neither option appear in target > container > If .optional == 1 and .seccomp is valid => only .seccomp appears in the > target > > It's also not possible to query its value or set it through the API.
I should have put RFC in the subject. I'm still not sure it's the right thing to do in any case. On the one hand, it helps for having a single config usable in many places. On the other hand, if I'm running something I distrust enough to confine it with seccomp, I'd prefer to not have to worry about whether 'lxc.seccomp.optional = 1' was set somewhere... Let's shelve this for now. Thanks for looking. _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
