[CRIU] is CR_STATE_RESTORE_CREDS necessary?

[Tycho Andersen]

On Mon, Dec 14, 2015 at 10:14:49AM +0300, Andrew Vagin wrote:
> On Fri, Dec 11, 2015 at 08:09:57AM -0700, Tycho Andersen wrote:
> > On Fri, Dec 11, 2015 at 05:48:42PM +0300, Andrew Vagin wrote:
> > > On Fri, Dec 11, 2015 at 12:11:10AM +0300, Pavel Emelyanov wrote:
> > > > Yes, that's clear -- we need global final sync point before total
> > > > unfreeze and resume.
> > 
> > Why doesn't CR_STATE_COMPLETE work for this? Doesn't the restorer wait
> > once it finishes CR_STATE_RESTORE_CREDS until it gets the signal for
> > CR_STATE_COMPLETE?
> 
> Because CRIU doesn't wait when the CR_STATE_COMPLETE stage will be
> completed.

Oh, duh :)

> > But this is really because of the network, not because of the creds.
> > What if we s/CR_STATE_RESTORE_CREDS/CR_STATE_NETWORK_UNLOCK, and in
> > the restorer only do rst_tcp_socks_all() here, and move all the creds
> > restore after CR_STATE_NETWORK_UNLOCK, when the main task sends
> > CR_STATE_COMPLETE.
> 
> I don't understand this. Do you want to restore creds after
> CR_STATE_COMPLETE?

No, I just want to restore creds after restore_seccomp, but that needs
seccomp suspended in order to work. Here's three commits:

https://github.com/tych0/criu/commits/seccomp-setuid

the first one adds a setuid() call to make it fail, the second moves
the restore_seccomp call to the "right" place causing it to pass
again. But then if we change the seccomp policy slightly, we can get
it to fail.

What I'm after is just a way to solve this problem.

> > 
> > The one problem this doesn't solve is someone mentioned in the thread
> > that there was an issue about resuming some tasks before other tasks
> > had their creds restored. I didn't understand this point, isn't this
> > prevented by the wait on __NR_rt_sigreturn (except in the case where
> > criu is itself ptraced, but I'm ignoring that one because I don't
> > think it's a use case other than for debugging).
> 
> Pls, don't ignore this usecases, it is enought critical to take it
> into account.

As a real use case, or just for debugging? For just debugging, I think
it is ok if some things don't work correctly in this state right?

Tycho