RE: I think there's a bug with p->sasl_maxbuf in cyrus.c

["Howard Chu" <hyc@symas.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Dave Snoopy

> Thanks.
>
> Incidentally, the correct way to check for SASL's read
> buffer size is with a call to:

> ldap_int_sasl_get_option(ld,
> LDAP_OPT_X_SASL_MAXBUFSIZE, &value);

Not in the sockbuf context. The code in the sockbuf handler has no notion of
the LDAP* ld handle. You're getting the separate abstraction layers mixed up.

But probably this should be using SASL_SEC_PROPS instead of SASL_MAXOUTBUF to
check the maxbuf. I think you're right about this bug but you should still
file the ITS report so it can be tracked.

> Unfortunately, doing this the proper way will break
> Windows 2000 compatibility if you're using the latest
> Cyrus-SASL (2.1.15). Why? I just noticed that my
> response packets from a Windows 2000 DC were sometimes
> quite large (~272KB). This is despite the fact that
> the SASL client maxbufsize (advertised to the server)
> is set by the OpenLDAP code by default to 65KB.

This is a well known bug. It's perhaps fortunate that their GSSAPI
implementation used a non-standard cipher, thus making them incompatible with
most of the world, and preventing standard clients from connecting and
crashing. Now that their non-standard ciphers are better supported (by MIT
and Heimdal) I guess we'll see more problems.

> Windows 2003 is better behaved, and never returns
> responses bigger than this.

Good to know.

> By a miracle though, everything still worked with
> Windows 2000 and SASL 2.1.4 up until now because the
> OpenLDAP code is using the wrong buffer size to check
> the size of the server response with. It's using the
> buffer size of how much we can write to the server,
> which is generally very large (> 4MB). But using the
> newer SASL against a 2000 DC results in this server
> buffer size being very small (~16KB) due to the flag
> misinterpretation I mentioned before. In other words,
> SNAFU.

That about sums it up...

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support