Possible SASL bug seen with long-ish ldapmodify updates

[Dan White]

On 01/06/15 23:15 +0000, Dameon Wagner wrote:
>I've been trying to solve an issue we're seeing with large batched
>ldapmodify update, and with the help of the kind people over at
>openldap-technical it seems that it may be more of a SASL issue than
>an openldap issue.  Given that, I thought I'd ask here too, in case it
>rings bells with anyone on the list.

>During the course of my testing (we've not seen this in production,
>thankfully) I've noticed that, with reasonably lengthy* updates for an
>entry, ldapmodify dies with an error like the following:

>As a work-around I can manually split up the list into several blocks
>(tested with roughly 1000 member updates per block) with "replace:
>member" for the first, to match the current behaviour, and "add:
>member" for the rest. In this format, ldapmodify is happy to process
>the LDIF (all in one connection, but as discreet operations totalling
>about 1000 lines of updates or roughly 67K of changes).  (Note: the
>authenticated user has "unlimited" limits in the config.)
>
>We're using Debian wheezy, with the authenticating with Kerberos using
>the libsasl2-modules-gssapi-heimdal Debian package of version
>2.1.25.dfsg1-6+deb7u1.  On the older system we're in upgrading away
>from we're using the lenny version of the package
>(2.1.22.dfsg1-23+lenny1 -- hence planning the upgrade).
>
>Has anyone on the list seen anything similar to the
>"sb_sasl_cyrus_decode" and "sb_sasl_generic_read" failures in
>situation like this?

I don't recall seeing those errors specifically, but I would guess there's
a bug here in the negotiation of the maximum security layer receive buffer
between libsasl and heimdal. I recall seeing some emails in years past
about it.

You can trouble shoot by using a libsasl compiled against MIT, or
experiment with olcSaslSecProps/sasl-secprops on the server, and
SASL_SECPROPS on the client. Try a large value for maxbufsize. See
slapd-config(5) and ldap.conf(5).

-- 
Dan White