make exec.fifo can be safety read

[ningmingxiao]

some people read-only mount /var/run into container,some process will read /run/runc/id/exec.fifo (for example antivirus apps) it will cause runc start failed.
after this commit /run/runc/id/exec.fifo has a lower risk of being misread even user doesn't ro bind /var/run into container. @kolyshkin @cyphar

[cyphar]

We need to be quite careful around changing this code, as there is a lot of history behind how we ended up with this fairly ugly FIFO solution.

The signalling model we have takes advantage of the fact that write to a FIFO will block until a reader appears and then you are guaranteed to continue running. This means that multiple runc start invocations will not block each other, and if (hypothetically) runc start crashes after opening the file descriptor runc init will still succeed. I think we tried doing it the way you've done in this PR and there was some deadlock scenario, though this was all ~10 years ago now so I can't quite remember the details.

We used to use signals and switched to the FIFO because of lots of issues with that model (signal coalescing and pid1 has special signal semantics). That being said, I wonder if SIGSTOP/SIGCONT would work (I think we used to use custom signals, which was a huge cause of issues).

some people read-only mount /var/run into container

This seems like A Very Bad Idea ™️ -- unix sockets are not protected by ro bind-mounts, and so if they are running a container process as root you can easily break out of the container through /var/run/docker.sock or various other sockets in /var/run (/var/run/cups/cups.sock would be fun to exploit thanks to the enormous amount of printer driver RCEs).

[ningmingxiao]

I can't prevent user bind /var/run into container. I find crun start will write data into the fifo. may be we can refer it.
and use this commit /run/runc/id/exec.fifo have a smaller time window will be misread.@cyphar