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.
Please provide a stack backtrace from the core dump. Kurt At 06:14 AM 6/17/00 GMT, 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. > > >
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. > > >
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.
Fixed, thanks. At 12:44 PM 6/17/00 -0400, Bradford L. Barrett wrote: > >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. > >
moved from Incoming to Software Bugs
changed notes changed state Open to Release
changed state Release to Closed
Fixed.