[Date Prev][Date Next] [Chronological] [Thread] [Top]


Looking at ITS#2944 and ITS#2956 I'm beginning to wonder why we have
SASL_MAX_BUFF_SIZE in ldap-int.h at all. I note that reverting the patch to
ITS#2184 fixes the current problems when using an OpenLDAP client against an
OpenLDAP server, but I suspect this isn't going to prevent running into
problems with other vendors' implementations.

Here is the fix I mentioned above:

diff -u -r1.99 cyrus.c
--- cyrus.c     24 Jan 2004 02:33:44 -0000      1.99
+++ cyrus.c     13 Feb 2004 00:46:53 -0000
@@ -356,14 +356,11 @@
        /* now encode the next packet. */
        ber_pvt_sb_buf_init( &p->buf_out );
-       /* sasl v2 makes sure this number is correct */
-       if ( len > *p->sasl_maxbuf )
-               len = *p->sasl_maxbuf;
        ber_pvt_sb_buf_destroy( &p->buf_out );
        if ( len > *p->sasl_maxbuf - 100 )
                len = *p->sasl_maxbuf - 100;    /* For safety margin */
        ret = sasl_encode( p->sasl_context, buf, len,
                (SASL_CONST char **)&p->buf_out.buf_base,
                (unsigned *)&p->buf_out.buf_size );

The safety margin that was originally in the code was removed after Larry
Greenfield from Cyrus advised us that it was not needed when using Cyrus SASL
2. Basically it insures that we write slightly less than sasl_maxbuf on each
iteration, so that after padding and other SASL overhead is added, we come in
under SASL_MAX_BUFF_SIZE. Currently if we do a GSSAPI write of sasl_maxbuf
bytes, the receiver gets sasl_maxbuf+12 bytes which is greater than
SASL_MAX_BUFF_SIZE and the packet is rejected.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support