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

[Saied Kazemi]

Really appreciate your flexibility Pavel.  For now, I've taken out criu
check from my script to prevent false alarms.  So it's not blocking
anything.  Will work on the patch first chance I get.

Re reverting Tycho's patch, yes, please go ahead and revert it.

Thanks,

--Saied


On Fri, Feb 19, 2016 at 10:05 AM, Pavel Emelyanov <xemul at virtuozzo.com>
wrote:

> 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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160219/72652665/attachment.html>