Rootless runc in the Nix sandbox

I'm trying to run runc --rootless in the Nix sandbox [1]. The container I'm using can be run outside of the sandbox, with my current user and with the same runc binary. In the Nix sandbox, I'm facing several issues that I describe in the following:

1. By default, the Nix sandbox environment doesn't have any cgroup fs in /sys/fs/cgroup. It fails with

container_linux.go:344: starting container process caused "process_linux.go:275: applying cgroup configuration for process caused \"mountpoint for cgroup not found\""

I need to bind mount /sys/fs/cgroup/devices in the Nix sandbox to go further.

2. With /sys/fs/cgroup/devices bind mounted, runc then fails with

container_linux.go:344: starting container process caused "process_linux.go:424: container init caused \"\""

Well, this is now a little bit more complex to understand:/ It seems to be related to the readOnlyPaths and maskPaths calls [2]. The parent process gets an EOF on the sync pipe but I don't know what is happening on the child side (actually, I don't know how to debug this part).
For testing purposes, I've removed the readOnlyPaths and maskPaths section in the config.json file.

3. Without any readOnlyPaths and maskPaths in the config.json file, runc fails with

container_linux.go:344: starting container process caused "read init-p: connection reset by peer"

Here some questions:

• How do you debug the init process? Are you able to print debug message?
• Is /sys/fs/cgroup/* required for rootless container?
• Why I don't get a better message in the step 2., ie. when readOnlyPaths are mounted? Is it because the child process is killed by something?
• And, of course, any idea on what is happening?

Thx.

[1] https://nixos.org/nix/manual/ grep sandbox :/
[2] https://github.com/opencontainers/runc/blob/master/libcontainer/standard_init_linux.go#L120-L129

Reproduce the rootless runc failure in the Nix sandbox, starting with the cgroup setup and the readOnlyPaths and maskPaths handling in libcontainer/standard_init_linux.go. Use the reported sync-pipe and connection-reset errors to investigate the init process and determine whether cgroups or path mounts cause the failure. Done means identifying the cause and documenting or fixing the failure with clearer diagnostics.