[CRIU] is CR_STATE_RESTORE_CREDS necessary?

[Pavel Emelyanov]

On 12/09/2015 08:05 PM, Tycho Andersen wrote:
> Hi all,
> 
> I'm trying to figure out a way to get rid of this FIXME:
> https://github.com/xemul/criu/blob/master/test/zdtm/live/static/seccomp_filter.c#L103
> 
> to do this, we need to call restore_seccomp() before restore_creds(),
> but if we're doing that, we need to suspend seccomp so that it doesn't
> kill the task if the policy has blocked some syscall that
> restore_creds does.
> 
> Right now, seccomp is suspended in attach_to_tasks(), because that's
> the last ptrace attach that criu does to the tasks. However, that
> happens after CR_STATE_RESTORE_CREDS, i.e. after the creds are
> restored.
> 
> I could just move the attach_to_tasks call above
> CR_STATE_RESTORE_CREDS, but I think that would deadlock since the main criu
> tasks waits for the tasks to be complete, but they're all in the
> stopped state (because we'd have ptraced them), and the loop that lets
> them run is in parasite_stop_on_syscall much further below.

And zombies are not yet picked up by pie code yet at this point I guess :\

> My idea here is to get rid of this CR_STATE_RESTORE_CREDS and just
> ptrace attach after CR_STATE_RESTORE_SIGCHLD and run the loop there.
> But, I'm not sure if CR_STATE_RESTORE_CREDS is used for anything. It
> doesn't seem necessary, but probably I'm missing something :)

It's sued to make sure we don't resume task A before task B turns into
proper security context (with uids, caps and so on). The RESTORE_CREDS stage
can be thought of the very final one that makes sure that _all_ tasks
are in fully restored state and we can unfreeze them one-by-one.

So doing s/RESTORE_CREDS/FINAL_SYNC_POINT/ or smth like this is worth 
doing to avoid confusion. But the question is whether we need a separate 
RESTORE_SIGCHILD stage is good. I remember that we need to sync all
tasks at this point to properly catch zombies w/o messing with other
tasks dying due to some restore errors.

-- Pavel