cyrus https signaled to death by Windows webdav #2198
Comments
|
Thanks for the detailed issue report. There were a couple of fixes on master the last weeks around XML namespace handling. Would it be possible for you to either test if the problem persists also on the master branch, or alternatively provide me with a the request body of the request that causes the crash? If the issue doesn't occur on master, I'll see to cherry-pick the fixes on the 3.0 branch. |
|
I've just compiled the master branch and tested the webdav mount and get the same result. I disabled https on the server, modified the registry on the Windows client to allow BASIC authentication over non-ssl http, and used tcpdump to collect a packet trace. The cyrus log corresponding to the below trace was the same as before but no SSL info (as expected as not using SSL): Full trace packet trace, host running cyrus 10.184.23.233, client running Windows 10 1703 64bit 10.184.22.132: |
|
We will need a core dump in order to see what is happening. |
What do we use floating point for in httpd/dav, is there a lot of it? |
|
@ksmurchison Thanks for those pointers. After running ulimit -c unlimited and launching /usr/lib/cyrus-imapd/master -d from /usr/lib/imap (owned by cyrus) a core dump was generated (see core.zip at the bottom of this post). The log file that went with this (from launching master to the termination) was: Jan 9 10:10:27 spice ctl_cyrusdb[11169]: skiplist: clean shutdown file missing, updating recovery stamp The command used to map the drive (from a Windows 7 Pro 32bit workstation) was: C:\Users\wtr30>net use * https://spice.prv.exeter.mercedes-benzsouthwest.co.uk/dav/drive/user/wtr30/ An unexpected network error occurred. |
|
@ksmurchison As requested: |
|
OK. The bug isn't in the DAV code, its in the SASL DIGEST-MD5 plugin. I've found that HTTP Digest auth isn't very interoperable between different implementations. It may or may not work with Windows. I regret that I even tried to implement it in Cyrus. I would either disable the DIGEST-MD5 plugin, or try setting sasl_reauth_timeout: 1 in imapd.conf |
|
@ksmurchison sasl_reauth_timeout: 1 causes Windows to prompt for a username and password (when it didn't before) but it still fails to authenticate. No crashing though. Windows command prompt: cyrus log: Based on your last comment should I assume we will consider the internal Windows 7 client 'badly behaved' and not try and hack cyrus to account for it? |
|
The client WILL have to authenticate. It would probably be worth disabling Digest all together and just use Basic. The easiest way to do this without effecting other Cyrus services is to set a service-specific sasl_mech_list for your Cyrus HTTP services. For instance, if you have a service named 'https' in cyrus.conf, add the following to imapd.conf: https_sasl_mech_list: PLAIN |
|
Now running with: When attempting to connect to the dav drive using the Windows Network Location Wizard I get the following core dump: cyrus log was: |
|
@ksmurchison Another core dump after a segfault, this time trying Webdrive a recommended third-party webdav client instead of the Windows 7 webdav-mini-redirector. The cyrus log that led to this was: That occured when trying to create a file on the share with 'Enable persistent connections (Keep-Alive)' disabled in the Webdrive connection settings. With the persistent connections option enabled (the default) files can be created, but directory creation fails with much repitition of: |
|
it maybe related, at least it is happening on CalDAV, with thunderbird (one under linux ubuntu 22.04, and another on windows 10 family). I have : Sep 22 15:02:37 iroco cyrus/master[1366]: process type:SERVICE name:http path:/usr/local/libexec/httpd age:0.029s pid:106163 signaled to death by signal 11 (Segmentation fault)
Sep 22 15:02:37 iroco kernel: [885066.187527] httpd[106163] segfault at 0 ip 00007fd9c9e1c559 sp 00007ffc08249208 error 4 in libcyrus_min.so.0.0.0[7fd9c9e11000+c000]
Sep 22 15:02:37 iroco kernel: [885066.187534] Code: 90 49 89 f8 48 89 d1 48 85 d2 74 35 31 c0 48 83 e9 01 48 89 f2 75 13 eb 3f 0f 1f 84 00 00 00 00 00 48 83 c0 01 48 39 c8 74 27 <0f> b6 14 06 41 88 14 00 84 d2 75 eb c3 66 2e 0f 1f 84 00 00 00 00 With cyrus 3.4.2. After the segfault, the service is restarted and is responding normally. Then if we repeat the "synchronize calendars" several times it crashes again, and so on. it is related to #4505 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I attempt to access webdav storage using a Windows client the http process on the server crashes. No core dump is generated. Tested with Windows 7 SP1 32bit and Windows 10 1703 with the same result. The webdav storage can be successfully mounted and used by a MacOS 10.12 client. SSL cert self-signed and added to the clients machine account Trusted Root Certificates store.
Mount command and error on Windows 7 (note this is identical on Windows 10):
C:\Users\wtr30>net use * https://spice.prv.citywest.com/dav/drive/user/wtr30/
System error 59 has occurred.
An unexpected network error occurred.
cyrus log:
Nov 11 13:02:10 spice https[8912]: inittls: Loading hard-coded DH parameters
Nov 11 13:02:10 spice https[8912]: starttls failed: ex-wrk-50.prv.citywest.com [10.184.22.172]
Nov 11 13:02:10 spice https[8913]: inittls: Loading hard-coded DH parameters
Nov 11 13:02:10 spice https[8913]: starttls failed: ex-wrk-50.prv.citywest.com [10.184.22.172]
Nov 11 13:02:10 spice https[8914]: inittls: Loading hard-coded DH parameters
Nov 11 13:02:10 spice https[8914]: starttls: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits new) no authentication
Nov 11 13:02:10 spice master[8892]: process type:SERVICE name:https path:/usr/lib/cyrus-imapd/httpd age:0.122s pid:8914 signaled to death by signal 8 (Floating point exception)
Followed the procedure on the cyrus wiki to enable core dumps but no core dump is generated.
cyrus 3.0.4 on CentOS 7 compiled with:
./configure --enable-idled --enable-sieve --enable-http --enable-calalarmd --prefix=/usr/local --libexecdir=/usr/lib/cyrus-imapd --sbindir=/usr/lib/cyrus-imapd
imapd.conf:
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
admins: cyrus
sieve_admins: cyrus
sievedir: /var/lib/imap/sieve
sendmail: /usr/sbin/sendmail
hashimapspool: true
sasl_pwcheck_method: saslauthd
allowplaintext: 1
sasl_mech_list: PLAIN LOGIN BASIC DIGEST-MD5
unixhierarchysep: yes
altnamespace: yes
allowusermoves: 1
tls_server_cert: /etc/pki/cyrus-imapd/selfsigned.pem
tls_server_key: /etc/pki/cyrus-imapd/key.pem
tls_client_ca_file: /etc/pki/tls/certs/ca-bundle.crt
idlesocket: /var/lib/imap/socket/idle
httpmodules: caldav carddav webdav
caldav_create_default: 1
caldav_create_attach: 1
caldav_create_sched: 1
cyrus.conf:
START {
recover cmd="ctl_cyrusdb -r"
}
SERVICES {
imap cmd="imapd" listen="imap" prefork=0
sieve cmd="timsieved" listen="sieve" prefork=0
lmtpunix cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=1
http cmd="httpd" listen="10.184.23.233:http" prefork=0
https cmd="httpd -s" listen="10.184.23.233:https" prefork=0
}
EVENTS {
checkpoint cmd="ctl_cyrusdb -c" period=30
delprune cmd="cyr_expire -E 3" at=0400
deleteprune cmd="cyr_expire -E 4 -D 28" at=0430
expungeprune cmd="cyr_expire -E 4 -X 28" at=0445
tlsprune cmd="tls_prune" at=0400
squatter cmd="/usr/lib/cyrus-imapd/squatter -i -r user" period=600
}
DAEMON {
idled cmd="idled"
}
The text was updated successfully, but these errors were encountered: