[CRIU] [PATCH] seccomp: add a --no-seccomp option to disable dumping seccomp

[Saied Kazemi]

The earliest I can work on cr_check() patch would be Tuesday next week
which is unfortunately after the freeze date of February 22nd.  Do you
still want me to do so?

--Saied



On Thu, Feb 18, 2016 at 2:49 AM, Pavel Emelyanov <xemul at virtuozzo.com>
wrote:

> On 02/17/2016 09:15 PM, Saied Kazemi wrote:
> > On Wed, Feb 17, 2016 at 9:36 AM, Pavel Emelyanov <xemul at virtuozzo.com
> <mailto:xemul at virtuozzo.com>> wrote:
> >
> >     On 02/17/2016 08:27 PM, Saied Kazemi wrote:
> >     > I am running the containers with --security-opt seccomp:unconfined
> option,
> >     > so there should be no security risks.
> >
> >     Ouch. Why does criu then sees some seccomp configured on it?
> >
> >
> > I think I know what happened.  I had a script that would build and
> install CRIU and then test Docker
> > checkpoint and restore.  The script was failing because criu check was
> failing but somehow I assumed
> > that it was criu dump that was failing although --security-opt
> seccomp:unconfined option was used.
> >  Sorry for the confusion :(
>
> Ah, I see. I will then roll-back Tycho's patch not to burden the API with
> the
> stuff we don't really need. OK?
>
> >     > Now what can we do to make criu check pass when running on kernels
> that
> >     > don't have seccomp?  The section "Checking That It Works" in
> >     > http://criu.org/Installation says that the users should see
> "Looks OK".
> >     > But currently we can't get a "Looks OK" message even with
> --no-seccomp.
> >     > Pavel had a suggestion on how to redo criu check.
> >
> >     Yup. We should distinguish tree types of features -- those, that are
> strictly
> >     required to make things work (/proc/pid/map_files, ptrace
> PEEKSIGINFO ,etc),
> >     those that are required, but only for "specific cases" (aio remap,
> tun, etc)
> >     and those that are experimental (e.g. task-diag from Andrey).
> >
> >
> > The 3-mode scheme sounds reasonable but which modes are absolutely
> necessary for
> > CRIU to dump and restore successfully.
>
> Looking at cr_check() I think that we 100% need everything till
> check_ptrace_peeksiginfo,
> as pretty much every task uses what we check with it.
>
> All the other stuff is optional and criu can succeed w/o them.
>
> And, by now, we have no experimental features in criu that require
> non-upstream kernel.
>
> > We maintained in the past that if users don't get "Looks OK" from criu
> check they won't
> > be able to dump/restore.  But that's not the case anymore as criu check
> fails with
> > seccomp errors but it successfully dumps and restores.
>
> Yes, I agree. Would you be able to prepare the patch to fix the cr-check
> untill
> criu-2.0 release?
>
> >     But as far as seccomp is concerned, I'm now in doubt -- if there's
> no seccomp
> >     configured on a task, criu should just dump it even if there's no
> support
> >     from kernel to dump seccomp. But this seems not to be the case for
> Saied.
> >
> >
> > Per my explanation above, sorry for the false alarm!
>
> That's OK :) Given enough eyeballs, all bugs are shallow.
>
> -- Pavel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160219/dc03c4ff/attachment.html>