[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
SASL MAX BUFF SIZE, ITS#2944, ITS#2956
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. */
#if SASL_VERSION_MAJOR >= 2
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;
#else
ber_pvt_sb_buf_destroy( &p->buf_out );
+#endif
if ( len > *p->sasl_maxbuf - 100 )
len = *p->sasl_maxbuf - 100; /* For safety margin */
-#endif
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