Re: Possible SASL bug seen with long-ish ldapmodify updates
Dan White <[email protected]>
| Newsgroups | gmane.comp.security.cyrus.sasl |
|---|---|
| Message-ID | <[email protected]> |
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. -- Dan White