Re: ldappasswd core dumps w/UFC-Crypt on Slack7 (ITS#598)

[brad@mrunix.net]

I manually applied the changes and it worked like a charm.. I must point
out though that the fix on line 194 (ldappasswd.c) which reads:

   if (crypted_pw==NULL || crypted_pw[0]='\0')
      return NULL;

probably should be (and what I used):

   if (crypted_pw==NULL || crypted_pw[0]=='\0')
      return NULL;

-> notice that the original fix forces crypted_pw[0] to be a zero, instead
   instead of testing for equality ;)

Thanks for the fast response, it really is appreciated!

--------------- Original Message ---------------
On Sat, 17 Jun 2000, Kurt D. Zeilenga wrote:

> Belay that request for a stack trace back...
> I've committed a quick fix the problem to OPENLDAP_REL_ENG_1_2.
> Please test.
> 
> >brad@mrunix.net wrote:
> >Full_Name: Bradford L. Barrett
> >Version: 1.2.11
> >OS: Slackware 7 base/2.2.15 kernel
> >URL: 
> >Submission from: (NULL) (208.60.255.34)
> >
> >
> >ldappasswd does a core dump (segfault) when attempting to change a password
> >using {CRYPT} on a Slackware 7 system w/UFC-Crypt (1.3) library installed.
> >I had the same problem with imap-4.7c and wound up having to modify the code to
> >check for a NULL return string before doing a strcpy in order to fix it..
> >It appears that the UFC code has changed a bit and requires the salt to
> >be in a unique format for it to work properly...  If it's not the right
> >format, the crypt(3) call just returns a NULL so a strcpy or other pointer
> >oriented operation segfaults hard :(  Other encryption methods work without
> >a problem (I've verified MD5 works fine).  I'll run a trace on the code and
> >see if I can pinpoint the exact location of the problem when I get a free
> >moment or two.

--
Bradford L. Barrett                      brad@mrunix.net
A free electron in a sea of neutrons     DoD#1750 KD4NAW

The only thing Micro$oft has done for society, is make people
believe that computers are inherently unreliable.