restore fails for pods with userns remap (spec.hostUsers: false)

[oOraph]

Using the following kubernetes feature fails with the zero pod runtime:
https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/

The pod with spec.hostUsers: false is correctly spawned and works well as long as it does not get scaled down

But after a scale down, criu fails to restore the suspended process

Can't unshare net-namespace: Operation not permitted\n(00.005268) PID: real 1840678 virt 1\n(00.005417) Error (criu/cr-restore.c:2080): Can't attach to init: Operation not permitted\n(00.005423) Warn  (criu/cr-restore.c:2307): Unable to wait 1840678: No child processes\n(00.005440) uns: calling exit_usernsd (-1, 1)\n(00.005463) uns: daemon calls 0x5574c3cce180 (1840674, -1, 1)\n(00.005473) uns: `- daemon exits w/ 0\n(00.005932) uns: daemon stopped\n(00.005937) Error (criu/cr-restore.c:2320): Restoring FAILED.\n(00.006957) Error (criu/cgroup.c:1998): cg: cgroupd: recv req error: No such file or directory\n" runtime=io.containerd.zeropod.v2

this might just be a criu misconfig, checking if there is some remap option to toggle on

[ctrox]

This is a known issue and I opened an upstream issue in criu but no progress so far. I also tried to debug it myself for a bit but I'm not too familiar with criu internals.

[oOraph]

interesting ! And it appears the criu + userns restoring reliability issue has been around for a while indeed. (Due to issues in restoring the original uid/gid maps if I understand correctly). I'm not closing the issue yet because I want to investigate sth like changing the runtime + checkpoint / restore mechanism to a micro vm framework for that specific use case (and verify that it's not a perf killer because the criu checkpoint restore speed was impressive)

[ctrox]

Yeah of course, it's totally reasonable to have this issue open until this is fixed. For integrating with something like kata, it would probably need a completely new shim based on the containerd-shim-kata-v2 instead of the runc one.