[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
ITS #910, ber_pvt_sb_do_write()
> -----Original Message-----
> From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]
> Howard Chu wrote:
> > -----Original Message-----
> > Subject: Re: bugfix disposition
> >
> >> ITS#910 - filed against 2.0.7 and left Suspended. Seems this
> code hasn't
> >> ever changed, but the bug itself is pretty unlikely in the first place.
> >> liblber/sockbuf.c
> >
> > A fix for this is needed.
> >
> >hyc< This is pretty surprising to me. The submitted patch looks
> fine, but I
> >hyc< was unable to reproduce any failure on Linux. Perhaps I
> need to use a
> >hyc< larger group, but the one I used was already 26K in size. I
> suppose an
> >hyc< entry with a jpeg file or somesuch would do just as well.
>
> I haven't tried, but: Did you use Cyrus sasl? ber_pvt_sb_do_write()
> is only used in libldap/cyrus.c:sb_sasl_write().
Yes. Unfortunately it is pretty much impossible for me to create the
conditions that trigger this bug. The only way is to cause a write that is
so big that it takes multiple attempts for the data to be pushed out onto
the network. On Linux, the default socket send buffer size is large enough
that writes of 64K succeed in one attempt. However, SASL has hardcoded
limits of 64K on its own internal buffers. So, any packet large enough to
trip this bug is rejected as invalid by the SASL encode and decode routines,
which makes it a moot point.
I've spent quite a few hours tweaking MAXBUFSIZ constants all over the LBER
and SASL libraries to allow me to recreate the bug but at this point I'm
sick of chasing it down.
I should note that this 64K limit (SASL_MAX_BUFF_SIZE) could be quite a
surprising limitation to run into, we need to doc it somewhere or find a way
to work around it.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support