[CRIU] Checkpoint/restore as non-root user

[Filipe Brandenburger]

Hi Pavel,

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.

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?

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?

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.

Cheers,
Filipe
 On Sep 22, 2014 10:02 AM, "Pavel Emelyanov" <xemul at parallels.com> wrote:

> On 09/20/2014 07:21 AM, Filipe Brandenburger wrote:
> > Hi,
> >
> > Have you considered using CRIU to checkpoint/restore processes without
> > requiring root privileges?
>
> We did. And so far we have two options for that -- launching criu
> as rpc service or giving the binary the suid bit.
>
> When used like this some security restrictions apply, we collected
> them at http://criu.org/Security
>
> > Of course that means the dumped/restored state might not be complete,
> > but I can see that it should be possible to preserve information about
> > the memory state and file descriptors (while not possible to preserve
> > PIDs, mounts, pending socket buffers, etc.)
>
> There will be problems with injecting parasite code -- the
> /proc/pid/map_files/
> links used to do this are CAP_SYS_<something> :(
>
> > This might be interesting for scenarios such as these (from
> > http://criu.org/Usage_scenarios):
> > - "Save" ability in apps (games), that don't have such
> > - Snapshots of apps
> >
> > That could be interesting even if changes to the application would be
> > necessary to support dump and restore. For example, if it was required
> > to link to a criu library and have the software call checkpoint()
> > periodically, and to handle restore from the application code as well.
>
> Yup, we've seen this case. If in library callers doesn't set the pid to
> dump the criu_dump() would dump the calling process :)
>
> > So, have you considered this possibility? Would that be something you
> > would be interested in having CRIU do? Or do you think that's not what
> > CRIU is all about and that it would be better handled by a different
> > project instead?
>
> We certainly consider this possibility. If you find the described way of
> doing this inappropriate, then we're fully open to discuss and improve it.
>
> Thanks,
> Pavel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20141016/d6f87016/attachment.html>