openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by hyc＠symas.com 24 Jun '11

24 Jun '11

Ian Puleston wrote: >> -----Original Message----- >> From: Howard Chu [mailto:hyc@symas.com] >> Sent: Wednesday, June 08, 2011 5:47 PM >> >> I'm pretty sure that this chunk can never do anything useful. >> ... >> The connection has just been created, asynchronously, so there's no way >> that >> the TLS layer was already started when it got here. > > After re-reviewing it I think you are correct. I put that in because I thought there may be a chance that ldap_int_tls_start could get called from ldap_int_open_connection if the connect completed very quickly in the underlying layers. But even if it did there has been no call to ldap_int_poll to check for it having completed. ldap_pvt_connect and then ldap_connect_to_host return -2 to ldap_int_open_connection on an async connect. And the latter then only calls ldap_int_tls_start if rc == 0, so that call will not happen. > >> Also, I suggest that you only check for CONNST_CONNECTING in the >> callers, and do the TLS check in the check function > > Yes, good idea. I guess that the way I have it allows it to start up TLS immediately if using TLS and the connect completes immediately, but if not using TLS it will return LDAP_X_CONNECTING. What you are suggesting means that if not using TLS and the connect completes immediately then it will be able to go ahead and send the request rather than retuning LDAP_X_CONNECTING. > > I will update the fix and supply a new patch shortly. No need, I already committed a fix to git. It is also in RE24. > > Thanks > Ian > > > > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

RE: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by ipuleston＠SonicWALL.com 24 Jun '11

24 Jun '11

> -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Wednesday, June 08, 2011 5:47 PM > > I'm pretty sure that this chunk can never do anything useful. > ... > The connection has just been created, asynchronously, so there's no way > that > the TLS layer was already started when it got here. After re-reviewing it I think you are correct. I put that in because I thought there may be a chance that ldap_int_tls_start could get called from ldap_int_open_connection if the connect completed very quickly in the underlying layers. But even if it did there has been no call to ldap_int_poll to check for it having completed. ldap_pvt_connect and then ldap_connect_to_host return -2 to ldap_int_open_connection on an async connect. And the latter then only calls ldap_int_tls_start if rc == 0, so that call will not happen. > Also, I suggest that you only check for CONNST_CONNECTING in the > callers, and do the TLS check in the check function Yes, good idea. I guess that the way I have it allows it to start up TLS immediately if using TLS and the connect completes immediately, but if not using TLS it will return LDAP_X_CONNECTING. What you are suggesting means that if not using TLS and the connect completes immediately then it will be able to go ahead and send the request rather than retuning LDAP_X_CONNECTING. I will update the fix and supply a new patch shortly. Thanks Ian

1 0

Re: (ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by jvcelak＠redhat.com 24 Jun '11

24 Jun '11

On Friday 24 June 2011 09:11:41, Howard Chu wrote: > >> There is no file ldifutil.c in OpenLDAP 2.4. > >> > >> I don't know what you're testing against, but this bug report appears > >> invalid. Closing. > > > > $ find -name ldifutil.c > > ./libraries/libldap/ldifutil.c > > ./libraries/libldap_r/ldifutil.c > > > > Tested against git master branch. > > Read again what I wrote. There is no file ldifutil.c in OpenLDAP 2.4. git > master is not the same as the 2.4 releases. Ouch, sorry. Then it is fixed only in master, not in RE24 (7cac590). $ ./ldapmodify -a -x -f /tmp/invalid.ldif -d2048 ldif_parse_line: missing ':' after dc=com ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain," Segmentation fault (core dumped) (gdb) bt #0 __strcasecmp_l_ssse3 () at ../sysdeps/x86_64/strcmp.S:214 #1 0x000000000040789c in process_ldif_rec (rbuf=0x67464e "objectclass: inetOrgPerson\nobjectclass: organizationalPerson\nobjectclass: person\nobjectclass: top\ncn: B\nsn: B\nuid: B\nmail: b(a)example.org\n", linenum=1) at ldapmodify.c:655 #2 0x00000000004067d5 in main (argc=6, argv=0x7fffffffdd88) at ldapmodify.c:335

1 0

Re: (ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by hyc＠symas.com 24 Jun '11

24 Jun '11

Jan Vcelak wrote: > On Thursday 23 June 2011 22:41:20, Howard Chu wrote: >> jvcelak(a)redhat.com wrote: >>> Full_Name: Jan Vcelak >>> Version: 2.5.25 >> >> There is no OpenLDAP version 2.5. > > This is a typo. I mean 2.4.25. (But it an older issue, it was reported in RH > bugzilla against 2.4.23.) > >> There is no file ldifutil.c in OpenLDAP 2.4. >> >> I don't know what you're testing against, but this bug report appears >> invalid. Closing. > > $ find -name ldifutil.c > ./libraries/libldap/ldifutil.c > ./libraries/libldap_r/ldifutil.c > > Tested against git master branch. Read again what I wrote. There is no file ldifutil.c in OpenLDAP 2.4. git master is not the same as the 2.4 releases. >> Your example doesn't SEGV for me. Anyway, I've committed a different patch >> to master for this issue. > > Strange... Fedora Linux 15, 64bit. And clearly an uninitialized memory was > accessed. But your fix is fine and works for me. > > Thank you. > > Jan > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by jvcelak＠redhat.com 24 Jun '11

24 Jun '11

On Thursday 23 June 2011 22:41:20, Howard Chu wrote: > jvcelak(a)redhat.com wrote: > > Full_Name: Jan Vcelak > > Version: 2.5.25 > > There is no OpenLDAP version 2.5. This is a typo. I mean 2.4.25. (But it an older issue, it was reported in RH bugzilla against 2.4.23.) > There is no file ldifutil.c in OpenLDAP 2.4. > > I don't know what you're testing against, but this bug report appears > invalid. Closing. $ find -name ldifutil.c ./libraries/libldap/ldifutil.c ./libraries/libldap_r/ldifutil.c Tested against git master branch. > Your example doesn't SEGV for me. Anyway, I've committed a different patch > to master for this issue. Strange... Fedora Linux 15, 64bit. And clearly an uninitialized memory was accessed. But your fix is fine and works for me. Thank you. Jan

1 0

Re: (ITS#6977) ldapwhoami minor verbose bugfix patch submission
by hyc＠symas.com 23 Jun '11

23 Jun '11

hyc(a)symas.com wrote: > checker(a)d6.com wrote: >> Full_Name: Chris Hecker >> Version: 2.4.25 >> OS: centos 5.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (98.248.126.162) >> >> >> Hi, ldapwhoami erroneously prints the "Result: Success (0)" string even if -v is >> not specified due to a minor bug in the code. Here is a fix. I am running >> 2.3.43, but just checked the latest repository version and the bug is still >> there (although at line 203 now), so I marked the version above as latest. >> >> Thanks, >> Chris > > It seems to me the better fix would be to change ldap_parse_result() to not > populate matcheddn or text when their values are zero-length. Kurt, any > particular reason things should continue to work as they currently do? OK, they work according to the C API draft. (sigh.) Client tools patched in master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6977) ldapwhoami minor verbose bugfix patch submission
by checker＠d6.com 23 Jun '11

23 Jun '11

Yeah, I just decided to do the same test as the two enclosed if statements to be 100% compatible. Chris On 2011/06/23 13:31, Howard Chu wrote: > checker(a)d6.com wrote: >> Full_Name: Chris Hecker >> Version: 2.4.25 >> OS: centos 5.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (98.248.126.162) >> >> >> Hi, ldapwhoami erroneously prints the "Result: Success (0)" string >> even if -v is >> not specified due to a minor bug in the code. Here is a fix. I am running >> 2.3.43, but just checked the latest repository version and the bug is >> still >> there (although at line 203 now), so I marked the version above as >> latest. >> >> Thanks, >> Chris > > It seems to me the better fix would be to change ldap_parse_result() to > not populate matcheddn or text when their values are zero-length. Kurt, > any particular reason things should continue to work as they currently do? > >> >> --- old/openldap-2.3.43/clients/tools/ldapwhoami.c 2008-02-11 >> 17:24:07.000000000 -0600 >> +++ openldap-2.3.43/clients/tools/ldapwhoami.c 2011-06-21 >> 14:15:28.000000000 >> -0500 >> @@ -215,7 +215,7 @@ >> >> skip: >> if ( verbose || ( code != LDAP_SUCCESS ) || >> - matcheddn || text || refs || ctrls ) >> + (matcheddn&& *matcheddn) || (text&& *text) || refs || ctrls ) >> { >> printf( _("Result: %s (%d)\n"), ldap_err2string( code ), code >> ); >> >> >> > >

1 0

Re: (ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by hyc＠symas.com 23 Jun '11

23 Jun '11

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: 2.5.25 There is no OpenLDAP version 2.5. > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20110622-ldif-split-indent-segfault… > Submission from: (NULL) (209.132.186.34) > > > Hello, > > input LDIF file with splitted lines which are indented incorrectly causes > SEGFAULT of a client tool. Let me show: > > $ cat /tmp/invalid.ldif > dn: cn=B,dc=my-domain, > dc=com > objectclass: inetOrgPerson > objectclass: organizationalPerson > objectclass: person > objectclass: top > cn: B > sn: B > uid: B > mail: b(a)example.org > > $ ldapmodify -a -x -f /tmp/invalid.ldif -d2048 > ldif_parse_line: missing ':' after dc=com > ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain," > Segmentation fault (core dumped) > > > (gdb) bt full > #0 __strcasecmp_l_ssse3 () at ../sysdeps/x86_64/strcmp.S:214 > No locals. > #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0, > linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1, > ctx=0x0) at ldifutil.c:399 There is no file ldifutil.c in OpenLDAP 2.4. I don't know what you're testing against, but this bug report appears invalid. Closing. > fv = 0 > line = 0x668627 "dc=com" > dn = 0x668614 "cn=B,dc=my-domain," > rc = -9 > modop = 0 > expect_modop = 0 > expect_sep = 0 > ldapadd = 1 > new_entry = 1 > delete_entry = 0 > got_all = 0 > pmods = 0x6697e8 > version = 0 > pctrls = 0x0 > i = 1 > j = 0 > k = -1 > idn = 1 > nmods = 1 > bvl = 0x6697f8 > bv = {bv_len = 0, bv_val = 0x0} > __PRETTY_FUNCTION__ = "ldap_parse_ldif_record_x" > #2 0x000000000042e524 in ldap_parse_ldif_record (rbuf=0x7fffffffdbb0, > linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1) at > ldifutil.c:565 > No locals. > #3 0x0000000000406ff8 in process_ldif_rec (rbuf=0x668610 "dn", linenum=1) at > ldapmodify.c:404 > lr = {lr_op = 0, lr_dn = {bv_len = 18, bv_val = 0x668614 > "cn=B,dc=my-domain,"}, lr_ctrls = 0x0, ldif_ops = {lr_mods = 0x0, ldif_op_rename > = {lr_newrdn = {bv_len = 0, > bv_val = 0x0}, lr_newsuperior = {bv_len = 0, bv_val = 0x0}, > lr_deleteoldrdn = 0}, ldif_op_ext = {lr_extop_oid = {bv_len = 0, bv_val = 0x0}, > lr_extop_data = { > bv_len = 0, bv_val = 0x0}}, ldif_op_cmp = {lr_cmp_attr = {bv_len > = 0, bv_val = 0x0}, lr_cmp_bvalue = {bv_len = 0, bv_val = 0x0}}}, lr_ctx = 0x0, > lr_lines = 2, > lr_lm = 0x6697d0, lr_mops = 0x0, lr_freeval = 0x6699e0 "", lr_vals = > 0x669930, lr_btype = 0x669880} > lrflags = 1 > rc = 0 > rbuf_bv = {bv_len = 0, > bv_val = 0x66862e "objectclass: inetOrgPerson\nobjectclass: > organizationalPerson\nobjectclass: person\nobjectclass: top\ncn: B\nsn: B\nuid: > B\nmail: b(a)example.org\n"} > #4 0x0000000000406cb7 in main (argc=6, argv=0x7fffffffdd98) at > ldapmodify.c:316 > rbuf = 0x668610 "dn" > rejbuf = 0x0 > rejfp = 0x0 > ldiffp = 0x6600a0 > ldifdummy = {fp = 0x0, prev = 0x0} > matched_msg = 0x448790 "H\211l$\330L\211d$\340H\215-\003\060!" > error_msg = 0x8000<Address 0x8000 out of bounds> > rc = 0 > retval = 0 > ldifrc = 1 > len = 4491152 > i = 0 > lineno = 1 > nextline = 11 > lmax = 4119 > c = {{ldctl_oid = 0x7fe0f05<Address 0x7fe0f05 out of bounds>, > ldctl_value = {bv_len = 5044973646, bv_val = 0x0}, ldctl_iscritical = 0 > '\000'}} > (gdb) frame 1 > #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0, > linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1, > ctx=0x0) at ldifutil.c:399 > 399 if ( !BV_CASEMATCH( lr->lr_btype+i,&bv )) { > (gdb) p *(lr->lr_btype+1) > $1 = {bv_len = 0, bv_val = 0x668627 "dc=com"} > (gdb) > > bv_len is set incorrectly to zero and therefore the string will be compared > against bv, which is a "null string". > > I have uploaded patch to address this issue. > > With the patch applied, the output is following: > > ./ldapmodify -a -x -f /tmp/invalid.ldif -d2048 > ldif_parse_line: missing ':' after dc=com > ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain," > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6977) ldapwhoami minor verbose bugfix patch submission
by hyc＠symas.com 23 Jun '11

23 Jun '11

checker(a)d6.com wrote: > Full_Name: Chris Hecker > Version: 2.4.25 > OS: centos 5.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (98.248.126.162) > > > Hi, ldapwhoami erroneously prints the "Result: Success (0)" string even if -v is > not specified due to a minor bug in the code. Here is a fix. I am running > 2.3.43, but just checked the latest repository version and the bug is still > there (although at line 203 now), so I marked the version above as latest. > > Thanks, > Chris It seems to me the better fix would be to change ldap_parse_result() to not populate matcheddn or text when their values are zero-length. Kurt, any particular reason things should continue to work as they currently do? > > --- old/openldap-2.3.43/clients/tools/ldapwhoami.c 2008-02-11 > 17:24:07.000000000 -0600 > +++ openldap-2.3.43/clients/tools/ldapwhoami.c 2011-06-21 14:15:28.000000000 > -0500 > @@ -215,7 +215,7 @@ > > skip: > if ( verbose || ( code != LDAP_SUCCESS ) || > - matcheddn || text || refs || ctrls ) > + (matcheddn&& *matcheddn) || (text&& *text) || refs || ctrls ) > { > printf( _("Result: %s (%d)\n"), ldap_err2string( code ), code > ); > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by hyc＠symas.com 23 Jun '11

23 Jun '11

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: 2.5.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20110622-ldif-split-indent-segfault… > Submission from: (NULL) (209.132.186.34) > > > Hello, > > input LDIF file with splitted lines which are indented incorrectly causes > SEGFAULT of a client tool. Let me show: Your example doesn't SEGV for me. Anyway, I've committed a different patch to master for this issue. > > $ cat /tmp/invalid.ldif > dn: cn=B,dc=my-domain, > dc=com > objectclass: inetOrgPerson > objectclass: organizationalPerson > objectclass: person > objectclass: top > cn: B > sn: B > uid: B > mail: b(a)example.org > > $ ldapmodify -a -x -f /tmp/invalid.ldif -d2048 > ldif_parse_line: missing ':' after dc=com > ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain," > Segmentation fault (core dumped) > > > (gdb) bt full > #0 __strcasecmp_l_ssse3 () at ../sysdeps/x86_64/strcmp.S:214 > No locals. > #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0, > linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1, > ctx=0x0) at ldifutil.c:399 > fv = 0 > line = 0x668627 "dc=com" > dn = 0x668614 "cn=B,dc=my-domain," > rc = -9 > modop = 0 > expect_modop = 0 > expect_sep = 0 > ldapadd = 1 > new_entry = 1 > delete_entry = 0 > got_all = 0 > pmods = 0x6697e8 > version = 0 > pctrls = 0x0 > i = 1 > j = 0 > k = -1 > idn = 1 > nmods = 1 > bvl = 0x6697f8 > bv = {bv_len = 0, bv_val = 0x0} > __PRETTY_FUNCTION__ = "ldap_parse_ldif_record_x" > #2 0x000000000042e524 in ldap_parse_ldif_record (rbuf=0x7fffffffdbb0, > linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1) at > ldifutil.c:565 > No locals. > #3 0x0000000000406ff8 in process_ldif_rec (rbuf=0x668610 "dn", linenum=1) at > ldapmodify.c:404 > lr = {lr_op = 0, lr_dn = {bv_len = 18, bv_val = 0x668614 > "cn=B,dc=my-domain,"}, lr_ctrls = 0x0, ldif_ops = {lr_mods = 0x0, ldif_op_rename > = {lr_newrdn = {bv_len = 0, > bv_val = 0x0}, lr_newsuperior = {bv_len = 0, bv_val = 0x0}, > lr_deleteoldrdn = 0}, ldif_op_ext = {lr_extop_oid = {bv_len = 0, bv_val = 0x0}, > lr_extop_data = { > bv_len = 0, bv_val = 0x0}}, ldif_op_cmp = {lr_cmp_attr = {bv_len > = 0, bv_val = 0x0}, lr_cmp_bvalue = {bv_len = 0, bv_val = 0x0}}}, lr_ctx = 0x0, > lr_lines = 2, > lr_lm = 0x6697d0, lr_mops = 0x0, lr_freeval = 0x6699e0 "", lr_vals = > 0x669930, lr_btype = 0x669880} > lrflags = 1 > rc = 0 > rbuf_bv = {bv_len = 0, > bv_val = 0x66862e "objectclass: inetOrgPerson\nobjectclass: > organizationalPerson\nobjectclass: person\nobjectclass: top\ncn: B\nsn: B\nuid: > B\nmail: b(a)example.org\n"} > #4 0x0000000000406cb7 in main (argc=6, argv=0x7fffffffdd98) at > ldapmodify.c:316 > rbuf = 0x668610 "dn" > rejbuf = 0x0 > rejfp = 0x0 > ldiffp = 0x6600a0 > ldifdummy = {fp = 0x0, prev = 0x0} > matched_msg = 0x448790 "H\211l$\330L\211d$\340H\215-\003\060!" > error_msg = 0x8000<Address 0x8000 out of bounds> > rc = 0 > retval = 0 > ldifrc = 1 > len = 4491152 > i = 0 > lineno = 1 > nextline = 11 > lmax = 4119 > c = {{ldctl_oid = 0x7fe0f05<Address 0x7fe0f05 out of bounds>, > ldctl_value = {bv_len = 5044973646, bv_val = 0x0}, ldctl_iscritical = 0 > '\000'}} > (gdb) frame 1 > #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0, > linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1, > ctx=0x0) at ldifutil.c:399 > 399 if ( !BV_CASEMATCH( lr->lr_btype+i,&bv )) { > (gdb) p *(lr->lr_btype+1) > $1 = {bv_len = 0, bv_val = 0x668627 "dc=com"} > (gdb) > > bv_len is set incorrectly to zero and therefore the string will be compared > against bv, which is a "null string". > > I have uploaded patch to address this issue. > > With the patch applied, the output is following: > > ./ldapmodify -a -x -f /tmp/invalid.ldif -d2048 > ldif_parse_line: missing ':' after dc=com > ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain," > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs