You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When you run exec with --detach you can already get the new process's
pidfd and pid before it runs, but nothing actually holds the process
there. The program can execve, and possibly exit, before whatever is
supervising it has finished adopting it. I didn't want to build out a
whole create/start style lifecycle for exec just to get that, when all
it really needs is a single wait point right before execve.
So this adds an opt-in --exec-wait-fifo <path>. The caller creates and
owns the fifo. runc passes it into the setns process, which does all of
its normal setup and then, just before execve, opens the fifo for
writing. That open blocks until something opens the read end, so a
supervisor can finish its handoff and then open the fifo to let the
program run. We write a byte and exec.
It's the same handshake create/start already use with the internal
exec.fifo, so this reuses that path (awaitExecFifo) instead of adding
another one. The O_PATH fd is closed before execve so the CVE-2016-9962
workaround still holds on old kernels. Nothing changes when the flag
isn't set.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
0 commit comments