Re: [Libguestfs] [PATCH libnbd 2/2] lib/crypto.c: Ignore TLS premature termination after write shutdown

On Wed, Jul 27, 2022 at 05:30:59PM +0100, Richard W.M. Jones wrote: > qemu-nbd doesn't call gnutls_bye to cleanly shut down the connection > after we send NBD_CMD_DISC. When copying from a qemu-nbd server (or > any operation which calls nbd_shutdown) you will see errors like this: > > $ nbdcopy nbds://foo?tls-certificates=/var/tmp/pki null: > nbds://foo?tls-certificates=/var/tmp/pki: nbd_shutdown: gnutls_record_recv: The TLS connection was non-properly terminated. > > Relatedly you may also see: > > nbd_shutdown: gnutls_record_recv: Error in the pull function. > > This commit suppresses the error in the case where we know that we > have shut down writes (which happens after NBD_CMD_DISC has been sent > on the wire). > --- > interop/interop.c | 9 --------- > lib/crypto.c | 17 +++++++++++++++++ > lib/internal.h | 1 + > 3 files changed, 18 insertions(+), 9 deletions(-) > > +++ b/lib/crypto.c > @@ -189,6 +189,22 @@ tls_recv (struct nbd_handle *h, struct socket *sock, void *buf, size_t len) > errno = EAGAIN; > return -1; > } > + if (h->tls_shut_writes && > + (r == GNUTLS_E_PULL_ERROR || r == GNUTLS_E_PREMATURE_TERMINATION)) { > + /* qemu-nbd doesn't call gnutls_bye to cleanly shut down the > + * connection after we send NBD_CMD_DISC, instead it simply > + * closes the connection. On the client side we see > + * "gnutls_record_recv: The TLS connection was non-properly > + * terminated" or "gnutls_record_recv: Error in the pull > + * function.". > + * > + * If we see these errors after we shut down the write side > + * (h->tls_shut_writes), which happens after we have sent > + * NBD_CMD_DISC on the wire, downgrade them to a debug message. > + */ > + debug (h, "gnutls_record_recv: %s", gnutls_strerror (r)); > + return 0; /* EOF */ > + } Nice. These are still hard errors if we have not sent NBD_CMD_DISC (the connection disappearing while we are using it could be a MitM attacker), but once we know we are done talking, tolerating a server abruptly disappearing instead of gracefully leaving is desirable. Reviewed-by: Eric Blake <eblake(a)redhat.com&gt;