El jue., 16 may. 2019 a las 19:06, David Lang (<[email protected]>) escribió: > > On Thu, 16 May 2019, Rainer Gerhards wrote: > > > El jue., 16 may. 2019 a las 9:09, David Lang (<[email protected]>) escribió: > >> > >> On Thu, 16 May 2019, Rainer Gerhards wrote: > >> > >>> El jue., 16 may. 2019 a las 7:46, David Lang via rsyslog > >>> (<[email protected]>) escribió: > >>>> > >>>> I saw a issue that said that the version of gnutls shipped in RHEL6 has > >>>> serious problems. I'm not finding detals easily, can someone give a brief > >>>> explination of the problem? > >>> > >>> I couldn't find the issue tracker, there exists at least one. The > >>> issue is that the version that comes with CentOS 6 segfaults from time > >>> to time. It abort with an internal error which starts with something > >>> like "Ohhh jeeeh" (or so ;-)) Newer versions don't have this issue. We > >>> tried hard to isolate this in rsyslog code, but it really looks like > >>> it is a GnuTLS issue. > >>> > >>> My approach is to suggest use of openSSL instead of GnuTLS. With > >>> openssl we can also generate much more meaningful error messages plus > >>> it's certificate handling is far superior. > >> > >> Ok, I may be able to contribute information here. At my new job (3 days > >> in) one > >> of the other admins tracked things down a bit more. > >> > >> forwarding info from an internal ticket: > >> > >> If a tls handshake is interrupted, there is a function that retries the > >> operation. it essentially takes a memory address of a typed defined > >> structure > >> "pNsd". A member of this structure (retryCall) is evaluated for the result > >> of a > >> TLS session (as conducted via gnutls_handshake()) and sets memory with the > >> result. If the result is non-zero an exception is entered. In this case the > >> exception returned can be tied back to an overflow (specifically, > >> GNUTLS_E_UNEXPECTED_PACKET_LENGTH as defned in gnutls.h). Since this > >> cannot be > >> handled, the code invokes a macro (ABORT_FINALIZE) which sets a global > >> vrable in > >> memory and then calls a goto statement called finalize_it - This does some > >> things, but ultimately sets a member ofpNsd (bAbortConn). This ultimately > >> causes > >> rsyslog to abort and die. > > > > The interesting there here is why it aborts. Any information on that? > > > > Is there a suggested way to handle this signal? If we cannot handle > > it, the right thing to do is to abort the connection,, which is done > > by setting bAbortConn. > > > I believe that the right thing to do is to abort the connection, but it seems > that rsyslog is dieing instead of just failing the connection (in this case, > it > seems to be an inbound connection) > > I walked into this by seeing a discussion of how to restart rsyslog when it > dies > from this.
Do you have any idea of how to reproduce this? If so, could you create a debug log and valgrind run? I still very much suggest to move to openssl - it really helps us generate much better error messages in case of a problem. Would still like to see this solved for gnutls. I think I tested inside the testbench and we never came to any result. What, btw, was a second driving force behind implementing openssl... Rainer > > David Lang > > > Rainer > >> > >> this was with 8.37 (and possibly 8.24) on RHEL6 (unknown generation) > >> > >> reading this, it seems to me that gnutls seems to be doing the right > >> thing, but > >> I am guessing that it's possible that the error that gets propodated back > >> to > >> rsyslog isn't being handled. > >> > >> But I have notlooked at the code. I've passed on the info that there were > >> problems with gnuTLS on RHEL 6 and suggested that there are lots of TLS > >> fixes in > >> more recent versions, but I figured I'd do a bit more digging on the > >> rsyslog > >> side to pass details of the problems back, It sounds as if the > >> detailed analysis may help track down the bug on the rsyslog side as well. > >> > >> David Lang > > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
