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
rather when xstrdup() tries to strlen() a
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
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
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
