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

[Pavel Emelyanov]

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