[openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Michael Wojcik]

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.[1]

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.

[1] There were no send, sendto, or sendmsg calls at the time. Now the argument applies equally to them.

Michael Wojcik
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...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170502/f3177e21/attachment-0001.html>