add lock mechanism or force unshare mnt to prevent multi intance clash

[BarryLhm]

i noticed some mount/umount operations is done during container setup, and this will probably cause race conditions. (if not operated in separate mount namespace)

a implementable solution is to create a lock file in /dev tmpfs and force a advisory lock during critical operations, or, just unshare beforehand.

this is to be further explored

[Moe-hacker]

For the cgroup setup, that's truly a problem. I didn't want to do mounts directly on host, but current implementation is also unsafe, I think we need to fork another process and do the setup in a new mount namespace that even other processes in container cannot access the cgroupfs.

[BarryLhm]

ps: this is not only for not leaking cgroup to container, but mostly for not lefting system in a inconsistent state in case of a interrupted/failed operation

[BarryLhm]

ahh, that would need a new fork wrapper

[BarryLhm]

and unsharing could not provent cgroupfs clash so we need another thing like /dev/ruri.lock on host

[Moe-hacker]

8879cf9
3bad8ad

ruri can use --auto-umount or --umount-on-panic to automatically trigger ruri_umount_container() on host side now.