Re: [musl] [bug] Ctrl-Z when process is doing posix_spawn makes the process hard to kill

[Markus Wichmann <nullplan@gmx.net>]

Hi all,

here is my understanding of the bug first.

1. Foreground process calls posix_spawn without the POSIX_SPAWN_SETSID
or POSIX_SPAWN_SETPGROUP flags (either of those prevent the bug).
2. User presses terminal suspend character between the parent process
masking signals and the child process execing the target program.
3. Kernel sends SIGTSTP to foreground process group.
4. SIGTSTP is blocked in parent process, so parent process does not
stop. Parent process is blocked in trying to read the pipe to the child,
though.
5. Child process unblocks signals before calling exec(), thereby
unblocking SIGTSTP and stopping.
6. User has an issue mainly because parent process never acts on SIGTSTP
and stops (which is why the shell's wait() call never returns).

Looking at the ingredients of the problem, it seems that unblocking
signals before reading the pipe would be the simplest way out of this
pickle. We cannot avoid blocking signals before calling clone() to spawn
the child with blocked signals, and they cannot be unblocked in exec(),
because all exec() functions pass on the signal mask, but the parent
could read the pipe with unblocked signals.

The code for reading the pipe and waiting for the child process
obviously would need to account for the possibility of EINTR, and there
is a possibility the pipe FD would escape to fork-without-exec in a
signal handler. That could be helped with FD_CLOFORK emulation in libc,
though (keep track of CLOFORK FDs in an FD set and close them all in
_Fork()), since FD_CLOFORK is not in the kernel, sadly.

Or else you could tell applications that weird things happen if you fork
in a signal handler without execing (that's weird usage, anyway).

Ciao,
Markus