[libvirt] [PATCH v3] util: Block SIGPIPE until execve in child process

[Eric Blake]

On 10/16/19 9:04 AM, Daniel P. Berrangé wrote:
> On Wed, Oct 16, 2019 at 06:50:33AM -0500, Eric Blake wrote:
>> On 10/16/19 4:02 AM, Daniel P. Berrangé wrote:
>>
>>>
>>> The challenge here is that we're in between fork + execve and want signal
>>> handlers back to their defaults at time of execve.
>>>
>>> If we set SIGPIPE to SIG_IGN and then execve() will that get reset back
>>> to SIG_DFL automatically ?
>>
>> Sadly, no.  execve() does not change whether a signal is ignored or masked
>> (ignored is more common - a number of CI systems have had issues where the
>> child inherits SIGPIPE ignored because the parent forgot to reset it, but
>> the child wasn't expecting it; but inheriting a signal masked is also a real
>> issue), with the lone exception of SIGCHLD. However, execve() _does_ change
>> a signal that is being caught in the parent into SIG_DFL post-exec.
>>
>> That does mean, however, that it is viable to install a no-op SIGPIPE
>> handler (SIGPIPE is generated but ignored, I/O gets the EPIPE as desired),
>> then post-exec the new process will have SIG_DFL.
> 
> Yeah, that's workable.
> 
> So we need virFork() to install a dummy SIGPIPE handler function that
> is a no-op, *before* it unmasks signals.

Why mask signals at all? You either mask the signal before I/O, install 
the dummy handler, then unmask (and any intermediate SIGPIPE is now 
ignored by no-op), or you can merely install the dummy handler before 
I/O (any SIGPIPE is ignored by no-op).  That is, by the time you 
identify a a safe place to install a mask (ie. no I/O between fork() and 
that point, but where there will be potential I/O between that point and 
exec), with plans to release it later, that same place is just as good 
for changing from SIG_IGN to a no-op handler without messing with masks.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org