[Date Prev][Date Next]
RE: I think there's a bug with p->sasl_maxbuf in cyrus.c
What you said about the max buffer sizes is true, but
it should only ever apply to writes, and not reads.
The server advertises the most data it can receive,
which means that SASL and or OpenLDAP needs to ensure
that it doesn't write more than this when it's used as
a client (i.e. ldapsearch performing a query).
The client also advertises how much data it can
receive, which means that SASL and or OpenLDAP needs
to ensure that it doesn't write more than this when
it's used as a server (i.e. the slapd LDAP server
writing a response).
The code in sb_sasl_read should not care about any
buffer sizes except those needed to store the data
read. In OpenLDAP's case, this is malloced anyway.
What is an ITS and how do I submit one?
--- Howard Chu <email@example.com> wrote:
> > -----Original Message-----
> > From: owner-openldap-software@OpenLDAP.org
> > [mailto:owner-openldap-software@OpenLDAP.org]On
> Behalf Of Dave Snoopy
> > Hi All,
> > I think there's a bug with p->sasl_maxbuf in
> > I'll explain what I think the bug is first, and
> > explain how I came across it afterward.
> > In either case, the incorrect parsing of the field
> > resulted in a server buffer size which was lower
> > the packet sizes that I was actually receiving
> > the server. I didn't think that this should really
> > matter, since I send very small packets (requests)
> > the server anyway. Researching this problem led me
> > the OpenLDAP find.
> Perhaps there's a bug here. The Cyrus code has
> changed enough times that we
> may have missed something. But the SASL RFCs (see
> RFC 2222 and 2831) specify
> that both the client and the server send each other
> a maxbuf value, and I
> presume that we have to honor it. A comment was made
> at one time that the
> SASL library insures this itself, so perhaps we can
> remove those checks. I've
> found that relying on the Cyrus SASL library to Do
> The Right Thing has often
> led to frustration... Maybe you should submit a new
> ITS for this if you
> actually want someone to investigate it.
> -- Howard Chu
> Chief Architect, Symas Corp. Director,
> Highland Sun
> Symas: Premier OpenSource Development and Support
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search