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

[Pavel Emelyanov]

On 02/19/2016 07:37 PM, Saied Kazemi wrote:
> 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?

Well, this would be a bugfix, as criu check doesn't work correctly at the moment.

I'm only worried with the fact that something is broken due to this in your experiments,
so if you need to have this fixed, I'm ready to merge the patch into 2.0 even if
it comes after feature freeze.

BTW, am I right, that Tycho's patch with --no-seccomp is no longer necessary and
I can roll back one?

-- Pavel

> --Saied
> 
> 
> 
> On Thu, Feb 18, 2016 at 2:49 AM, Pavel Emelyanov <xemul at virtuozzo.com <mailto: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> <mailto: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
> 
>