[openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write
Michael.Wojcik at microfocus.com
Tue May 2 15:27:20 UTC 2017
It may be worth noting that nearly all well-written UNIX applications should set the disposition of SIGPIPE to SIG_IGN. (Preferably using sigaction, simply because that's now the preferred API, but doing it with signal is essentially equivalent in this case.)
SIGPIPE is a hack. It exists only to terminate poorly-written programs that could otherwise block a pipeline. See Bach, The Design of the UNIX Operating System; if memory serves, Bach quotes Dennis Ritchie on this point. SIGPIPE was introduced because some poorly-written programs did not check the return code from write.
Catching SIGPIPE in a custom handler is nearly always the Wrong Thing. The correct approach, 99.9% of the time, is to set the disposition to SIG_IGN and check the results of each system call.
Personally, I think it's completely acceptable for a library to note in its documentation that the calling program MUST ignore SIGPIPE, or the library may not function properly. It's arguably OK for a library to check the disposition of SIGPIPE and if it's SIG_DFL, change it to SIG_IGN, on the grounds that the calling program is not well-written so it doesn't deserve to govern its own signal handling; but it's probably better to just fail in that case, either immediately (with a diagnostic that tells the user that the developer forgot to set the disposition of SIGPIPE) or when a SIGPIPE occurs.
Libraries can't accommodate all forms of invalid behavior. You can do a certain amount of defensive coding, but at some point you're diminishing functionality for well-behaved applications in order to coddle bad ones. Don't do that.
 There were no send, sendto, or sendmsg calls at the time. Now the argument applies equally to them.
Distinguished Engineer, Micro Focus
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of mahesh gs
Sent: Monday, May 01, 2017 23:59
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write
Yes, ours is a library and we do not wish to ignore the signal process wide because the consumer of our library (application) might want to handle the SIGPIPE for there own socket handling.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users