[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: sasl_encode type conflict in 64 bit builds (ITS#3212)
Kurt,
The change you've made works beautifully. I wasn't able to just "plop" your
new cyrus.c on top of my existing configuration so I've spent the better
part of the day fighting with configure and our weird, non-standard build
environment. I've built ldapsearch for 64 bit and 32 bit Solaris/SPARC
platforms and run it successfully. I used a SASL bind, selected the
DIGEST-MD5 mechanism and fetched the RootDSE from our 3 servers (OpenLDAP,
Sun Java System Directory Server and Active Directory) and it's all working
beautifully and it's working beautifully from SunOS in 64 and 32 bit form.
Regards,
Jeff
-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, June 29, 2004 9:36 AM
To: jeff.lewis29@verizon.net
Cc: openldap-its@OpenLDAP.org
Subject: Re: sasl_encode type conflict in 64 bit builds (ITS#3212)
Your fix, I believe, is correct. I've committed changes based upon it to
HEAD. Please test.
Kurt
At 12:18 AM 6/29/2004, jeff.lewis29@verizon.net wrote:
>Full_Name: Jeff Lewis
>Version: 2.1.17
>OS: SunOS 5.8
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (192.127.94.7)
>
>
>I'm an open source novice and have run into a problem building the
>OpenLDAP clients on SunOS. This very well could be a cockpit error on
>my part and I'd be delighted to learn that it's my error.
>
>I think I've stumbled upon a type conflict that's keeping the ldap
>client tools from working. I just built the clients on my SunOS
>platform with is a big endian 64 bit machine. When I run ldapsearch
>(and ldapwhoami...haven't tried the others but I suspect they'll do
>something similar), I get the following
>results:
>
> $ ./ldapsearch -b "" -s base -h tnt80 -U djl -Y DIGEST-MD5
> SASL/DIGEST-MD5 authentication started Please enter your password:
> SASL username: djl
> SASL SSF: 128
> SASL installing layers
> # extended LDIF
> #
> # LDAPv3
> # base <> with scope base
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> ldapsearch: ldap_search_ext: Can't contact LDAP server (81) $
>
>I did a network trace and found that the bind was successful, but the
>very next write/send to the server carrying the search request had "run
>away" and was sending a massive amount of data. After some study, I
>found my way into sb_sasl_write in the libraries/libldap/cyrus.c source
>module. In it is a call to sasl_encode that is failing for me. What's
>happening is the sasl_encode() call wants a pointer to an "unsigned
>int" and sb_sasl_write passes a pointer to a ber_len_t cast as
>"unsigned *". The ber_len_t type wants to be "unsigned long" which is
>8 bytes wide on my 64 bit machine. The bottom line is sasl_encode
>stores 4 bytes of unsigned data into an 8 byte area, and since my
>machine is big endian, the resulting value is 2^^32 times bigger than
>it should be and the next write tries to send a huge amount of data. If my
machine were small endian, I wouldn't have noticed a problem.
>
>I figured that if there were a sasl_encode() call in the OpenLDAP
>source, there's probably a sasl_decode() call as well. I found it in
>sb_sasl_read and sure enough, it suffers from the same problem.
>
>Knowing that I'm not running the latest OpenLDAP package, I downloaded
>the latest stable release (2.2.13, I think), configured it and examined the
source.
>I did not build the package. But from desk checking the code and type
>definitions, it appears that this little problem of mine is still there.
>
>For now, I've added some code to copy the lengths into and out of an
>unsigned temp variable and passed a pointer to the temp to
>sasl_encode/decode. The code is much happier and produces good results for
me.
>
>Here's the original call to sasl_encode:
>
> ret = sasl_encode( p->sasl_context, buf, len,
> (SASL_CONST char **)&p->buf_out.buf_base,
> (unsigned *)&p->buf_out.buf_size );
>
>Here's my kludged call:
>
> temp = p->buf_out.buf_size;
> ret = sasl_encode( p->sasl_context, buf, len,
> (SASL_CONST char **)&p->buf_out.buf_base,
> (unsigned *)&temp );
> p->buf_out.buf_size = temp;
>
>I did something similar to the sasl_decode call in sb_sasl_read.
>
>If you're interested in the diffs:
>
> $ diff cyrus.orig cyrus.c
> 227a228
> > unsigned temp;
> 292a294
> > temp = p->buf_in.buf_end;
> 296c298,299
> < (unsigned *)&p->buf_in.buf_end );
> ---
> > (unsigned *)&temp );
> > p->buf_in.buf_end = temp;
> 321a325
> > unsigned temp;
> 350a355
> > temp = p->buf_out.buf_size;
> 353c358,359
> < (unsigned *)&p->buf_out.buf_size );
> ---
> > (unsigned *)&temp );
> > p->buf_out.buf_size = temp;
> $
>
>
>My ldapsearch is much much better after the changes, but I doubt
>seriously you'd want these particular changes in your code. They're a
>bit of a kludge and are completely wasteful on 32 bit platforms. But
>after making the changes above, here's what ldapsearch does for me
(correctly, I presume):
>
> $ ./ldapsearch -b "" -s base -h tnt80 -U djl -Y DIGEST-MD5
> SASL/DIGEST-MD5 authentication started Please enter your password:
> SASL username: djl
> SASL SSF: 128
> SASL installing layers
> # extended LDIF
> #
> # LDAPv3
> # base <> with scope base
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> #
> dn:
> objectClass: top
> objectClass: OpenLDAProotDSE
>
> # search result
> search: 3
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
> $
>
>I've searched the archives and did not see anything that caused me to
>think someone else was having a similar problem. But then, being an
>open source novice, I could have very easily missed something
>important. :-) I do hope this is enough information for you to go on.
>If not, email me and I'll fill in any missing blanks. Like I said, I'd
>be very happy to learn that the error is mine.