Possible SASL bug seen with long-ish ldapmodify updates
dwhite at olp.net
Wed Jan 7 14:05:52 EST 2015
On 01/07/15 16:10 +0000, Dameon Wagner wrote:
>On Wed, Jan 07 2015 at 08:46:51 -0600, Dan White scribbled
>> 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)?
Since this is merely a work around, you should use a value big enough to
support any individual sasl "session" that you anticipate having.
>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.
You should file a bug report so with as much detail at you can, and the
developers may ask for additional details if they need them.
>And just to doublecheck, maxbufsize is measured in bytes (meaning
>16777215 would be ~16MB)?
I believe so, yes.
More information about the Cyrus-sasl