Re: bin/60275: sh(1): race condition in signal handling on background subshell fork

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 19 May 2026 17:16:38 -0400
    From:        Christos Zoulas <christos%zoulas.com@localhost>
    Message-ID:  <0817055A-FBA0-4939-BD0A-52ED5884B94A%zoulas.com@localhost>


  | Perhaps it is time to ditch vfork() in sh and use posix_spawn() instead.

We might be able to do that for the vfork() case, perhaps, I will consider
it as a possible enhancement, but the suggestion for SA_RESETFORK was more
for the fork() case (Taylor's original issue), the vfork() version would
just come along for the ride in that case.   We certainly can't replace
the uses of fork() in sh with posix_spawn().

  | Otherwise the only solution is to block the relevant signals and save
  | signal handlers bebore vfork() and then restore/unblock them once the
  | child is done.

That is more or less what was done to fix the fork() issue.   Fixing the
vfork() case just needed to be a bit more careful how that was done, and
also what's done in the signal handler, if in a vfork() child, should one
be called.

Having SA_RESETFORK as a sigaction flag would save all those extra sys calls,
plus all the ones that the child after either fork variant needs to do to
return all the caught signals back to SIG_DFL.

kre