Re: sync_client segmentation fault when using TLS
On 08 Apr 2010, at 16:32, Matt Selsky wrote: Can you add this patch to bugzilla? Is this the same as: https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3174 My patch for that is below. :wes sync_client-tls-capability-response.diff Description: Binary data Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sync_client segmentation fault when using TLS
Raphael, Can you add this patch to bugzilla? -- Matt Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sync_client segmentation fault when using TLS
Dietmar Rieder wrote: Hi, we just updated our master + replication servers from 2.3.13 to 2.3.16 and discovered, that the sync_client is dying with a segfault when it connects to the replication server which has set "allowplaintext: no". We managed to trace down the problem and came up with the following patch against imap/backend.c to solve it. Gernot & Didi p.s.: Allowing plaintext authentication by "allowplaintext: yes" on the replication server would also be an option as workarround ... but not for us :-) --- backend.c.orig Thu Apr 23 19:10:05 2009 +++ backend.c Tue Jan 12 23:39:24 2010 @@ -93,7 +93,7 @@ resp = (automatic == AUTO_BANNER) ? prot->banner.resp : prot->capa_cmd.resp; -if (!automatic) { +if (!automatic && (prot->capa_cmd.cmd!=NULL)) { /* no capability command */ if (!prot->capa_cmd.cmd) return NULL; @@ -449,7 +449,8 @@ if ((server[0] != '/') || (strcmp(prot->sasl_service, "lmtp") && strcmp(prot->sasl_service, "csync"))) { - char *mlist = xstrdup(mechlist); /* backend_auth is destructive */ + char *mlist=NULL; + if (mechlist) mlist= xstrdup(mechlist); /* backend_auth is destructive */ if ((r = backend_authenticate(ret, prot, &mlist, userid, cb, auth_status))) { As I mentioned in a previous post in this thread, I was having the same problem at our site following a 2.3.13 to 2.3.16 upgrade, and tried the patch included above. As this appeared to introduce another problem, I spent some time analyzing the situation and came up with the following, similar patch (also included as an attachment), which only alters the behavior of ask_capability in backend.c when invoked within sync_client instead of all callers. While I realize that this is probably not the best approach, it does address the problem at hand without requiring a deeper understanding best left to the developers and without the potential of introducing undesirable side effects on other components that rely on backend.c. --- backend.c 2009-04-23 12:10:05.0 -0500 +++ backend.c 2010-03-30 15:58:22.0 -0500 @@ -93,7 +93,7 @@ resp = (automatic == AUTO_BANNER) ? prot->banner.resp : prot->capa_cmd.resp; -if (!automatic) { +if (!automatic && strcmp(prot->sasl_service, "csync")) { /* no capability command */ if (!prot->capa_cmd.cmd) return NULL; @@ -449,7 +449,8 @@ if ((server[0] != '/') || (strcmp(prot->sasl_service, "lmtp") && strcmp(prot->sasl_service, "csync"))) { - char *mlist = xstrdup(mechlist); /* backend_auth is destructive */ +char *mlist = NULL; + if (mechlist) mlist = xstrdup(mechlist); /* backend_auth is destructive */ if ((r = backend_authenticate(ret, prot, &mlist, userid, cb, auth_status))) { There are really two problems affecting sync_client that were introduced by the new version, both of which are triggered when the sync_client attempts to authenticate to the sync_server. More on this later. As I seem to be one of only two users on this list who reported this problem, I'm led to believe that there's something about our two installations that's unique compared to everyone else's. To satisfy my curiosity as to why such problem could go unnoticed by anyone else for several months I'd like to compare my setup with other list members who are using replication. I tested 2.3.16 replication on the following platforms: Dell PE2950III dual quad core / 32 bit RHEL 4.7 Dell PE2950III dual quad core / 32 bit RHEL 5.4 Relevant config snippets: From master /etc/cyrus.conf: syncclient cmd="sync_client -r" From master /etc/imapd.conf: guid_mode: sha1 sync_host: somehost.somedomain.tld sync_authname: csync sync_password: * sync_log: 1 sync_shutdown_file: /var/lib/imap/sync_shutdown From replica /etc/cyrus.conf: syncservercmd="sync_server" listen="csync" From replica /etc/imapd.conf: sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN allowplaintext: no sasl_minimum_layer: 128 tls_cert_file: /etc/pki/tls/certs/cert.pem tls_ca_file: /etc/pki/tls/certs/chain.pem tls_key_file: /etc/pki/tls/private/key.pem tls_cipher_list: !ADH:MEDIUM:HIGH guid_mode: sha1 From replica /etc/sysconfig/saslauthd: MECH=pam The banner presented by sync_server: $ telnet localhost 2005 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. * STARTTLS * OK somehost.somedomain.tld Cyrus sync server v2.3.16 Observations: There are no mechs in the banner for ask_capability() to return, hence ask_capability() returns NULL mechlist. This causes backend_connect() to segfault when it tries to xstrdup() mechlist before calling backend_authenticate(), or rat
Re: sync_client segmentation fault when using TLS
Raphael Jaffey wrote: > > Dietmar Rieder wrote: >> Hi, >> >> we just updated our master + replication servers from 2.3.13 to 2.3.16 >> and discovered, that the sync_client is dying with a segfault when it >> connects to the replication server which has set "allowplaintext: no". >> >> We managed to trace down the problem and came up with the following >> patch against imap/backend.c to solve it. >> >> Gernot & Didi >> >> p.s.: >> Allowing plaintext authentication by "allowplaintext: yes" on the >> replication server would also be an option as workarround ... but not >> for us :-) >> > > I had a working environment with a master server running on 32 bit > RHEL4.7 and version 2.3.13 of cyrus, and a replica running on 32 bit > RHEL5.4 and version 2.3.16 of cyrus. I then upgraded the master to > 2.3.16 and now the sync_client segfaults immediately. I tried testing > with plaintext allowed to no avail, after which I disabled TLS for the > sync service (syncserver_tls_cert_file: disabled) with no improvement. > > The output from tcpdump indicates that the TCP session closes down > immediately after the server sends the banner. > > I tried the patch supplied by Dietmar, which didn't fix the problem and > in addition, rendered the master non-operational. > > I take it from the lack of followup on this thread, that this is not a > problem experienced by the majority if any of the folks on this list. > > Has anyone else experienced anything like this? > > Any suggestions as to what might cause this before I dust off my > debugging skills and attempt to trace the cause? > Update: I forgot to mention that I'm using the Invoca 2.3.16-1 package. Also, the same problem occurs when I try to replicate between two fresh installations of 2.3.16-1 on two fresh installations of 32 bit RHEL5.4. Rafe Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sync_client segmentation fault when using TLS
Dietmar Rieder wrote: > Hi, > > we just updated our master + replication servers from 2.3.13 to 2.3.16 > and discovered, that the sync_client is dying with a segfault when it > connects to the replication server which has set "allowplaintext: no". > > We managed to trace down the problem and came up with the following > patch against imap/backend.c to solve it. > > Gernot & Didi > > p.s.: > Allowing plaintext authentication by "allowplaintext: yes" on the > replication server would also be an option as workarround ... but not > for us :-) > I had a working environment with a master server running on 32 bit RHEL4.7 and version 2.3.13 of cyrus, and a replica running on 32 bit RHEL5.4 and version 2.3.16 of cyrus. I then upgraded the master to 2.3.16 and now the sync_client segfaults immediately. I tried testing with plaintext allowed to no avail, after which I disabled TLS for the sync service (syncserver_tls_cert_file: disabled) with no improvement. The output from tcpdump indicates that the TCP session closes down immediately after the server sends the banner. I tried the patch supplied by Dietmar, which didn't fix the problem and in addition, rendered the master non-operational. I take it from the lack of followup on this thread, that this is not a problem experienced by the majority if any of the folks on this list. Has anyone else experienced anything like this? Any suggestions as to what might cause this before I dust off my debugging skills and attempt to trace the cause? Thanks, Rafe Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
sync_client segmentation fault when using TLS
Hi, we just updated our master + replication servers from 2.3.13 to 2.3.16 and discovered, that the sync_client is dying with a segfault when it connects to the replication server which has set "allowplaintext: no". We managed to trace down the problem and came up with the following patch against imap/backend.c to solve it. Gernot & Didi p.s.: Allowing plaintext authentication by "allowplaintext: yes" on the replication server would also be an option as workarround ... but not for us :-) --- backend.c.orig Thu Apr 23 19:10:05 2009 +++ backend.c Tue Jan 12 23:39:24 2010 @@ -93,7 +93,7 @@ resp = (automatic == AUTO_BANNER) ? prot->banner.resp : prot->capa_cmd.resp; -if (!automatic) { +if (!automatic && (prot->capa_cmd.cmd!=NULL)) { /* no capability command */ if (!prot->capa_cmd.cmd) return NULL; @@ -449,7 +449,8 @@ if ((server[0] != '/') || (strcmp(prot->sasl_service, "lmtp") && strcmp(prot->sasl_service, "csync"))) { - char *mlist = xstrdup(mechlist); /* backend_auth is destructive */ + char *mlist=NULL; + if (mechlist) mlist= xstrdup(mechlist); /* backend_auth is destructive */ if ((r = backend_authenticate(ret, prot, &mlist, userid, cb, auth_status))) { Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html