On 22 mar 2013, at 00:24, Bill MacAllister <whm@xxxxxxxxxxxx> wrote:
>
>
> --On Monday, February 11, 2013 03:58:49 PM +0100 Ragnar Sundblad <ragge@xxxxxxxxxx> wrote:
>
>>
>> On 11 feb 2013 - w7, at 00:04, Ragnar Sundblad <ragge@xxxxxxxxxx> wrote:
>>
>>> We get "encoded packet size too big (8252 > 8192)" paired with
>>> "decoding error: generic failure; SASL(-1): generic failure: security
>>> flags do not match required, closing connection" when the imap proxy
>>> is talking to the imapd.
>>>
>>> I have tracked down the "too big" message to _plug_decode() in
>>> plugins/plugin_common.c.
>>
>> We have looked into this a little further.
>>
>> First a clarification:
>> Above we had upped the buffer both in imapd (PROT_BUFSIZE in
>> <imapd>/lib/prot.h) and in sasl (SASL_ENCODEV_EXTRA in
>> <sasl>/lib/common.c to 8192. Before that change, the numbers
>> typically were "(4156 > 4096)".
>>
>> We are now using sasl with SASL_ENCODEV_EXTRA=8192 (double the
>> original value, and imapd with PROT_BUFSIZE=4096 (as it were
>> originally), and everything finally seems to work now.
>>
>> The sasl GSSAPI plugin sets oparams->maxoutbuf to 8132 (8192 - 60),
>> but it seems the imapd stuff still sends packets which in clear
>> text are PROT_BUFSIZE, which get 60 bytes larger when encrypted,
>> and which then would be to large if we hadn't upped sasl's
>> SASL_ENCODEV_EXTRA.
>>
>> So something doesn't really work correctly here.
>
> Did you ever figure out what the underlying issue was?
No, we don't know why this is, yet at least.
It seems that the imapd sometimes writes to large clear text blobs to
the GSSAPI layer, which makes the GSSAPI plugin generate to large
packets (of course).
We have temporarily "fixed" it with:
--- prot.c.DIST 2013-02-21 13:33:22.544751444 +0100
+++ prot.c 2013-02-22 12:22:44.155846743 +0100
@@ -89,13 +89,17 @@ struct protgroup
struct protstream *prot_new(int fd, int write)
{
struct protstream *newstream;
newstream = (struct protstream *) xzmalloc(sizeof(struct protstream));
newstream->buf_size = PROT_BUFSIZE;
newstream->buf = (unsigned char *)
xmalloc(sizeof(char) * (newstream->buf_size));
newstream->ptr = newstream->buf;
newstream->maxplain = newstream->buf_size;
+ if ( write ) { /* XXX */
+ newstream->maxplain -= 120; /* 60 would probably do */
+ }
newstream->fd = fd;
newstream->write = write;
newstream->logfd = PROT_NO_FD;
newstream->big_buffer = PROT_NO_FD;
> We are seeing a problem that looks a lot like this yours. From JNDI
> clients connecting to our OpenLDAP server on Debian Wheezy connections
> are failing. If the client makes a GSSAPI connection and uses SASL
> encryption then the client will fail with a
> java.lang.NegativeArraySizeException error.
Interesting. Is the remote end sending a negative buffer size?
Maybe the 2.1.25 gssapi module can do that. I don't think we have
seen that particular problem.
> The problem Cyrus SASL version is 2.1.25. Also, the problem is
> limited to Java JNDI clients since our non-Java clients appear to
> be working. The same failing Java applications work with version
> 2.1.23.
>
> We have experimented and found that the problem is in the SASL
> encryption layer. If we configure configure the Java client to use
> GSSAPI authentication and TLS encryption the clients can retrieve LDAP
> data.
/ragge
