<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 17, 2016 at 9:36 AM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@virtuozzo.com" target="_blank">xemul@virtuozzo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/17/2016 08:27 PM, Saied Kazemi wrote:<br>
> I am running the containers with --security-opt seccomp:unconfined option,<br>
> so there should be no security risks.<br>
<br>
</span>Ouch. Why does criu then sees some seccomp configured on it?<br></blockquote><div><br></div><div>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 :(</div><div> </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Now what can we do to make criu check pass when running on kernels that<br>
> don't have seccomp? The section "Checking That It Works" in<br>
> <a href="http://criu.org/Installation" rel="noreferrer" target="_blank">http://criu.org/Installation</a> says that the users should see "Looks OK".<br>
> But currently we can't get a "Looks OK" message even with --no-seccomp.<br>
> Pavel had a suggestion on how to redo criu check.<br>
<br>
</span>Yup. We should distinguish tree types of features -- those, that are strictly<br>
required to make things work (/proc/pid/map_files, ptrace PEEKSIGINFO ,etc),<br>
those that are required, but only for "specific cases" (aio remap, tun, etc)<br>
and those that are experimental (e.g. task-diag from Andrey).<br></blockquote><div><br></div><div>The 3-mode scheme sounds reasonable but which modes are absolutely necessary for CRIU to dump and restore successfully. 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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But as far as seccomp is concerned, I'm now in doubt -- if there's no seccomp<br>
configured on a task, criu should just dump it even if there's no support<br>
from kernel to dump seccomp. But this seems not to be the case for Saied.<br></blockquote><div><br></div><div>Per my explanation above, sorry for the false alarm!</div><div><br></div><div>--Saied</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> On Wed, Feb 17, 2016 at 6:50 AM, Tycho Andersen <<a href="mailto:tycho.andersen@canonical.com">tycho.andersen@canonical.com</a> <mailto:<a href="mailto:tycho.andersen@canonical.com">tycho.andersen@canonical.com</a>>> wrote:<br>
><br>
> On Wed, Feb 17, 2016 at 05:41:28PM +0300, Pavel Emelyanov wrote:<br>
> > On 02/17/2016 05:15 PM, Tycho Andersen wrote:<br>
> > > On Wed, Feb 17, 2016 at 01:48:37PM +0300, Pavel Emelyanov wrote:<br>
> > >> Applied.<br>
> > >><br>
> > >> Am I right, that the current behavior of criu is -- no seccomp configured<br>
> > >> on a process means no attempt to dump one is performed?<br>
> > ><br>
> > > I think so, just to restate: if no seccomp is configured on the<br>
> > > process than no attempt to dump the /seccomp/ stuff is made (since<br>
> > > there's nothing to dump). The task itself is still dumped as usual.<br>
> ><br>
> > OK :) Then Saied is potentially doing a dangerous thing with this option :)<br>
> > since tasks will be restored without seccomp stuff configured in.<br>
><br>
> Yes, exactly. It does a pr_warn when it encounters this, at least.<br>
><br>
> Tycho<br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>