UNIX socket restore in non-root container fails with "Unable to change ownership to (0, 0): operation not permitted"

[hdrodz]

We are mainly running into this issue when checkpointing and restoring Java processes that have had jstack run on them.

To reproduce: inside a container running as a non-root user (e.g. nobody):

1. Start a Java process in the background. Grab its PID p.
2. Run jstack against p. This also creates a UNIX socket /tmp/.java_pid${p}.
3. Grab a checkpoint of p with criu dump.
4. Restore p from that same checkpoint. Restore fails with the error shown below.

Error output tail:

(00.015929)      7: unix: ghost: bind id 0x18 ino 47314041 addr /tmp/.java_pid7.tmp
(00.015936)      7: unix: ghost: socket id 0x18 ino 47314041 name /tmp/.java_pid7.tmp detected F_OK /tmp
(00.015939)      7: unix: ghost: socket id 0x18 ino 47314041 name /tmp/.java_pid7.tmp creating /tmp
(00.016098)      7: Error (criu/util.c:1028): Unable to change [-100]//tmp/.java_pid7.tmp ownership (65534, 65534) to (0, 0): Operation not permitted
(00.016168)      7: Error (criu/sk-unix.c:1651): unix: Can't bind id 0x18 ino 47314041 addr /tmp/.java_pid7.tmp: Operation not permitted
(00.016197)      7: Error (criu/files.c:1221): Unable to open fd=5 id=0x18
(00.016752) Error (criu/cr-restore.c:1258): 7 exited, status=1
(00.016788) Error (criu/cr-restore.c:2324): Restoring FAILED.

I have a simple setup that reproduces this. Configurations I've been able to reproduce this on:

• Debian bookworm + CRIU 3.19
• Debian trixie + CRIU 3.19
• Debian trixie + CRIU 4.1.1
• Debian trixie + criu-dev HEAD

[rst0git]

@hdrodz It looks like CRIU is running only with CAP_CHECKPOINT_RESTORE and you need enable a few more capabilities.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.