Possible SASL bug seen with long-ish ldapmodify updates

[Dameon Wagner]

On Wed, Jan 07 2015 at 08:46:51 -0600, Dan White scribbled
 in "Re: Possible SASL bug seen with long-ish ldapmodify updates":
> 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.

I don't think it's specific to heimdal, as I'm pretty sure I tried
against the libsasl2-modules-gssapi-mit package too, with the same
outcome.  I'll dig a little in the archive, and see if anything pops
out.

> 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).

tweaking maxbufsize appears to have done the trick, though I'd like to
know what you would consider a large value (or generally what you
would consider a sensible value for a server with 32GB doing little
other than running a low traffic postgresql DB and a slapd master)?

I'm currently testing with maxbufsize=1572864 (and also maxbufsize=0,
but I'm guessing that that disables some of the security?) Looking at
the code, I'm guessing 16777215 (0xFFFFFF) is the maximum value?

There are a couple of things in the Changelog that could, to my naïve
eye be linked, but if it is a bug it was introduced at some point
after 2.1.22 (where it doesn't appear to cause any trouble).

Thanks so much for the help, you've saved me a lot of worry, and if
there's any info that I can pass on that would help in tracking down
the bug, I'd be happy to gather from my test systems what I can and
hand it over.

And just to doublecheck, maxbufsize is measured in bytes (meaning
16777215 would be ~16MB)?

Thanks again Dan.

Cheers.

Dameon.

-- 
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Dameon Wagner, Systems Development and Support Team
IT Services, University of Oxford
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><