<p dir="ltr">Hi Pavel,</p>
<p dir="ltr">Following up on it, the idea here is to see how much we could do in criu to dump/restore an image without requiring (real) root privileges.</p>
<p dir="ltr">So, one point you raised was that to set the pid we need root, but maybe we could do that inside a user namespace and maybe patch the kernel to allow userns root to set the pids inside the pidns?</p>
<p dir="ltr">You mentioned the concern of the user modifying an image on disk and restoring it, but in a sense that's akin to attaching gdb to a process and modifying its memory and that's already possible without root, right?</p>
<p dir="ltr">Do you think it would be a good feature to exploit? Even if we can't support everything (e.g. ttys) I think it would be useful in many cases.</p>
<p dir="ltr">Cheers,<br>
Filipe<br>
</p>
<div class="gmail_quote">On Sep 22, 2014 10:02 AM, "Pavel Emelyanov" <<a href="mailto:xemul@parallels.com">xemul@parallels.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/20/2014 07:21 AM, Filipe Brandenburger wrote:<br>
> Hi,<br>
><br>
> Have you considered using CRIU to checkpoint/restore processes without<br>
> requiring root privileges?<br>
<br>
We did. And so far we have two options for that -- launching criu<br>
as rpc service or giving the binary the suid bit.<br>
<br>
When used like this some security restrictions apply, we collected<br>
them at <a href="http://criu.org/Security" target="_blank">http://criu.org/Security</a><br>
<br>
> Of course that means the dumped/restored state might not be complete,<br>
> but I can see that it should be possible to preserve information about<br>
> the memory state and file descriptors (while not possible to preserve<br>
> PIDs, mounts, pending socket buffers, etc.)<br>
<br>
There will be problems with injecting parasite code -- the /proc/pid/map_files/<br>
links used to do this are CAP_SYS_<something> :(<br>
<br>
> This might be interesting for scenarios such as these (from<br>
> <a href="http://criu.org/Usage_scenarios" target="_blank">http://criu.org/Usage_scenarios</a>):<br>
> - "Save" ability in apps (games), that don't have such<br>
> - Snapshots of apps<br>
><br>
> That could be interesting even if changes to the application would be<br>
> necessary to support dump and restore. For example, if it was required<br>
> to link to a criu library and have the software call checkpoint()<br>
> periodically, and to handle restore from the application code as well.<br>
<br>
Yup, we've seen this case. If in library callers doesn't set the pid to<br>
dump the criu_dump() would dump the calling process :)<br>
<br>
> So, have you considered this possibility? Would that be something you<br>
> would be interested in having CRIU do? Or do you think that's not what<br>
> CRIU is all about and that it would be better handled by a different<br>
> project instead?<br>
<br>
We certainly consider this possibility. If you find the described way of<br>
doing this inappropriate, then we're fully open to discuss and improve it.<br>
<br>
Thanks,<br>
Pavel<br>
<br>
</blockquote></div>