Date: Fri, 8 Nov 2002 11:04:32 -0500 (EST)
From: Peter Krotkov <[EMAIL PROTECTED]>
[...]
22335: imapd -s
ff09b3bc read (0, 1c4bc8, 6f5)
0008e8c8 sock_read (0, 1c4bc8, 6f5, 8e8a0, 18edf8, 1) + 28
0008d670 BIO_read (1bd090, 1c4bc8, 6f5, 1c32a8, 1bccf0, 0) + d0
0007dec8 ssl3_read_n (5, 2010, 2010, 191b, 0, 0) + 148
0007e140 ssl3_get_record (1bb7e0, 1bccf0, 0, 0, 23138, ff0941d8) + 1e0
0007e8d4 ssl3_read_bytes (1bb7e0, 17, 1aa610, 1000, 0, 1bccf0) + 1d4
0007c6e8 ssl3_read (1bb7e0, 1aa610, 1000, 7c6a0, 19a1ac, 0) + 48
0006e730 SSL_read (1bb7e0, 1aa610, 1000, 1, ff0bd194, ffbec4b8) + 70
00060524 prot_fill (ffffffff, 0, 1000, 19cfb0, ffbec7b8, 1) + 340
00060d8c prot_read (0, ffbec7b8, 1000, 19cfb0, 1, ffbec7b8) + 6c
00050894 message_copy_strict (0, 19cfb0, 8008c, ffffeff8, 1a17a8, ff09c648) + 64
00044584 append_fromstream (ffbed830, 1a17a8, 9408c, 3cbce214, 1d0520, 1) + 14c
This one looks like the one that's actually having the problem. If you
kill this process, everything will return to normal.
What caused this? Well, prot_fill() isn't suppose to call SSL_read if
SSL_read is going to block. Unfortunately, it doesn't succeed in this
case.
Really, we should put the SSL socket into non-blocking mode and have
some additional logic to make sure this doesn't happen. Since the prot
layer itself is (generally) blocking, it's not totally trivial and we
haven't done the work.
Finally, there's the larger issue that we lock the mailbox during an
APPEND which is a Bad Idea, since a client can be arbitrarily slow
uploading data and thus creates a DoS for other clients. Avoiding this
isn't probably that hard (the staging code used by lmtpd can probably
be adapted by imapd) but we haven't done it, either.
At the very least, I'd appreciate it if you open a bug on the SSL
issue and include the backtrace on bugzilla.andrew.cmu.edu.
Larry
