[Date Prev][Date Next]
RE: handling of sasl packet sizes (ITS#2184)
> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of email@example.com
> It might be fair to expect, but that assumption is certainly not
> covered in any protocol document. A busy server might want to have
> small receive buffers (it gets lots of small commands frequently) but
> large send buffers (so that it can efficiently send lots of data to a
> few clients at a time).
Now this makes a lot of sense to me, but that's not how the library works.
There's only a single sasl_secprops.maxbufsize that an application can
configure, so there is no way to specify separate receive and transmit buffer
> I note that there are still buffer size bugs in Cyrus SASL 2.1.9;
> the digestmd5.c and srp.c mechs still limit buffer sizes to 0xFFFF
> instead of 0xFFFFFF as required by RFC2222. There really should
> have been a manifest constant defined for this in the Cyrus headers
> to prevent these problems in the first place. Currently we have
> SASL_MAX_BUFF_SIZE defined in libldap's ldap-int.h (at 65536, which
> is off by one) and this value should have come from sasl.h, it
> should not be OpenLDAP's responsibility to define this value.
> I don't understand what you're concerned about. OpenLDAP can set this
> value (input to the SASL library) to any number it wants. The SASL
> library will ensure correct on-the-wire behavior.
No. If we choose a max buffer size of 128K instead of our default of 64K,
digestmd5 will refuse to decode such a large message. See lines 1219 and 1535
of plugins/digestmd5.c. The same error exists in srp.c.
> RFC 2222 doesn't require any sort of minimum supported buffer size.
RFC 2222 specifies that a message length is encoded in 3 octets. That means a
buffer size up to 0xFFFFFF is legal. All of the plugins should function
correctly with a message that large, regardless of whether they can be
configured with a smaller default. The Cyrus library should define a manifest
constant for this value (0xFFFFFF) and use it everywhere, and export it for
applications to use because it is an intrinsic property of the SASL protocol.
> There might be individual mechanisms with smaller limits than what
> OpenLDAP supports, but this will not cause any interoperability
No, see ITS#2179, it is already causing interoperability problems. Even if we
set secprops to allow a maxbuf of 0xFFFFFF the mech itself will fail when it
receives a message larger than 0xFFFF.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support