- openldap-bugs - openldap.org

ITS#6886
by masarati＠aero.polimi.it 01 Jul '11

01 Jul '11

(should be) fixed in master, please test. p.

1 0

ITS#6873
by masarati＠aero.polimi.it 01 Jul '11

01 Jul '11

Fixed in master, please test. p.

1 0

Re: (ITS#6925) [PATCH] Use inet_ntop for server when available
by Pierangelo Masarati 30 Jun '11

30 Jun '11

Please provide patch as a file, not embedded in email. Upload instructions here <http://www.openldap.org/devel/contributing.html#submitting>. p.

1 0

"database monitor" documentation
by Dan Pritts 30 Jun '11

30 Jun '11

Hi, Looking for docs for the monitor datbase backend, i found this: http://www.openldap.org/devel/admin/monitoringslapd.html Like most other database backends, the monitor backend does honor slapd(8) access and other administrative controls. As some monitor information may be sensitive, it is generally recommend access to cn=monitor be restricted to directory administrators and their monitoring agents. Adding an access directive immediately below the database monitor directive is a clear and effective approach for controlling access. For instance, the addition of the following access directive immediately below the database monitor directive restricts access to monitoring information to the specified directory manager. access to * by dn.exact="cn=Manager,dc=example,dc=com by * none I have misunderstood acl and database config before, but I assume that the ACL here is in error, and something like this from slapd-monitor(5) is appropriate: access to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,dc=my,dc=org" write by users read by * none Assuming I'm correct please update the web docs & let me know. thanks! danno -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224

2 1

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by andrew.findlay＠skills-1st.co.uk 30 Jun '11

30 Jun '11

On Thu, Jun 30, 2011 at 03:11:05AM -0700, Howard Chu wrote: > Well since you raise the question, what do you think is the more > sensible approach to all of this? I was the one who argued in > ldapext that these attributes should be no-user-modification but > perhaps that makes them too inconvenient to administer. I think that the best approach would be to make no change in 2.4 code but to flag in the docs that the behaviour will change for 2.5. The NO-USER-MODIFICATION flags have been in draft-behera since 2005, but draft-zeilenga-ldap-relax has only been around since 2007. The latter document says that rules may not be relaxed unless there is a document saying that they may be. pwdAccountLockedTime is not mentioned in draft-zeilenga-ldap-relax and the relax control is not mentioned in draft-behera-ldap-password-policy, so one of those docs needs updating to make the behaviour legal. It would be interesting to survey other LDAP implementations to see how they currently treat the password-policy attributes. This is already a minefield due to uncertainties and variations in the replication process. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by hyc＠symas.com 30 Jun '11

30 Jun '11

Andrew Findlay wrote: > On Thu, Jun 09, 2011 at 01:45:17AM -0700, Howard Chu wrote: > >> I note that in ppolicy.c we have: >> >> { "( 1.3.6.1.4.1.42.2.27.8.1.17 " >> "NAME ( 'pwdAccountLockedTime' ) " >> "DESC 'The time an user account was locked' " >> "EQUALITY generalizedTimeMatch " >> "ORDERING generalizedTimeOrderingMatch " >> "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " >> "SINGLE-VALUE " >> #if 0 >> /* Not until Relax control is released */ >> "NO-USER-MODIFICATION " >> #endif >> "USAGE directoryOperation )", >> >> We have in fact released support for the Relax control, so it's >> probably time to unifdef these bits and go back to the documented >> behavior. > > That seems reasonable in the long term, though it will break many sites' > existing password management procedures. The change will have to be > mentioned in the updated manpage, noting the version at which it takes > effect. > > Should I produce an updated version of the manpage patch? Well since you raise the question, what do you think is the more sensible approach to all of this? I was the one who argued in ldapext that these attributes should be no-user-modification but perhaps that makes them too inconvenient to administer. -- -- 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

(ITS#6981) slapd crashes when using sssvlv and pcache overlays
by ctcard＠hotmail.com 30 Jun '11

30 Jun '11

Full_Name: Chris Card Version: HEAD as of 28 Jun 2011 OS: centos 5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.194.158.133) I am running slapd with pcache and sssvlv overlays and back-sql backend. With an empty cache, when I do a request like this: ldapsearch -h localhost -x -b "............" -D "............" -w ........ '(o=.....)' -E \!sss=mail:CaseIgnoreIA5Match slapd crashes in pcache_op_cleanup(), line 2369: /* check for malformed entries: attrs with no values */ { Attribute *a = rs->sr_entry->e_attrs; /* <-- HERE */ because rs->sr_entry is NULL. This appears to be because of the call to rs_flush_entry() in result.c line 1408 which sets rs->sr_entry to NULL prior to the call to pcache_op_cleanup(). The relevant part of my slapd.conf looks like this: database sql suffix "......" rootdn "......" rootpw ...... dbname MySQL dbuser ...... subtree_cond "ldap_entries.dn like CONCAT('%',?)" insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" has_ldapinfo_dn_ru no baseobject upper_func UPPER autocommit yes overlay pcache pcache bdb 10000 1 50 100 pcacheAttrset 0 * + pcacheTemplate (objectClass=) 0 60 pcacheTemplate (o=) 0 60 ... pcache-directory /var/tmp/cache pcache-cachesize 100 pcache-index objectClass eq,pres overlay sssvlv sssvlv-max 10 sssvlv-maxpercon 5

1 0

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by andrew.findlay＠skills-1st.co.uk 30 Jun '11

30 Jun '11

On Thu, Jun 09, 2011 at 01:45:17AM -0700, Howard Chu wrote: > I note that in ppolicy.c we have: > > { "( 1.3.6.1.4.1.42.2.27.8.1.17 " > "NAME ( 'pwdAccountLockedTime' ) " > "DESC 'The time an user account was locked' " > "EQUALITY generalizedTimeMatch " > "ORDERING generalizedTimeOrderingMatch " > "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " > "SINGLE-VALUE " > #if 0 > /* Not until Relax control is released */ > "NO-USER-MODIFICATION " > #endif > "USAGE directoryOperation )", > > We have in fact released support for the Relax control, so it's > probably time to unifdef these bits and go back to the documented > behavior. That seems reasonable in the long term, though it will break many sites' existing password management procedures. The change will have to be mentioned in the updated manpage, noting the version at which it takes effect. Should I produce an updated version of the manpage patch? Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

(ITS#6980) Patch - Mozilla NSS - memleak - have to free the return from SSL_PeerCertificate
by rmeggins＠redhat.com 29 Jun '11

29 Jun '11

Full_Name: Rich Megginson Version: 2.4.25 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.25-moznss-free-return-of-SSL_P… Submission from: (NULL) (76.113.106.30) In tlsm_auth_cert_handler, we get the peer's cert from the socket using SSL_PeerCertificate. This value is allocated and/or cached. We must destroy it using CERT_DestroyCertificate. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

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

28 Jun '11

Ian Puleston wrote: > There is something missing from the fix. I just had a problem where an asynchronous connect was failing and the result was continuous looping with repeated calls to ldap_sasl_bind. > > The problem is that if the connect fails, ldap_int_poll called from ldap_int_check_async_open gets an error and returns -1, and then -1 is returned up the stack ldap_int_check_async_open -> ldap_send_initial_request -> ldap_sasl_bind. But when ldap_sasl_bind gets that -1 return from ldap_send_initial_request it returns ld->ld_errno, and nowhere have we set that. In fact, ld->ld_errno still contains LDAP_X_CONNECTING from when the initial connect was issued, and so ldap_sasl_bind returns LDAP_X_CONNECTING, and that is what leads to the infinite looping that I see. Thanks for the analysis and fix. Now patched in master. In the future please send actual diffs, as noted http://www.openldap.org/devel/contributing.html > What is missing is that in ldap_int_check_async_open this: > > default: > return -1; > > Should be changed to: > > default: > ld->ld_errno = LDAP_CONNECT_ERROR; > return -1; > > 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 28 Jun '11

28 Jun '11

There is something missing from the fix. I just had a problem where an asynchronous connect was failing and the result was continuous looping with repeated calls to ldap_sasl_bind. The problem is that if the connect fails, ldap_int_poll called from ldap_int_check_async_open gets an error and returns -1, and then -1 is returned up the stack ldap_int_check_async_open -> ldap_send_initial_request -> ldap_sasl_bind. But when ldap_sasl_bind gets that -1 return from ldap_send_initial_request it returns ld->ld_errno, and nowhere have we set that. In fact, ld->ld_errno still contains LDAP_X_CONNECTING from when the initial connect was issued, and so ldap_sasl_bind returns LDAP_X_CONNECTING, and that is what leads to the infinite looping that I see. What is missing is that in ldap_int_check_async_open this: default: return -1; Should be changed to: default: ld->ld_errno = LDAP_CONNECT_ERROR; return -1; Ian

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by jvcelak＠redhat.com 27 Jun '11

27 Jun '11

LDIF functionality is included in libldif, but the interface is not provided (ldif.h is not installed by make install). This happens for RE24 branch, master branch is fine. Patch: ftp://ftp.openldap.org/incoming/jvcelak-20110627-export-ldif-h.patch Jan

1 0

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

25 Jun '11

Thanks Howard. I pulled your change out of GIT and tested it, and it works fine for me. However, just as an FYI, this line in open.c results in a "suggest parentheses around && within ||" warning from gcc with the compiler options that we use to compile our OpenLDAP port, and that in turn results in a build failure (since we use -Werror): if (rc == 0 && ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 ) The parentheses that I had in that line in my patch avoided that. Ian

1 0

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

25 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 25 Jun '11

25 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 24 Jun '11

24 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 24 Jun '11

24 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

(ITS#6979) test062 portability
by richton＠nbcs.rutgers.edu 23 Jun '11

23 Jun '11

Full_Name: Aaron Richton Version: RE24 OS: irrelevant URL: Submission from: (NULL) (166.217.78.192) It looks like checking the function exit isn't portable; maybe some kind of bash-ism. It looks like the code was on the path to communicating the retval via $RCOUT file already? As such, here's one quick workaround, although I'd love something a bit more elegant: --- test062-config-delete~ 2011-06-23 07:21:01.387583000 -0400 +++ test062-config-delete 2011-06-23 07:21:14.884787000 -0400 @@ -106,7 +106,7 @@ ( $LDAPSEARCH -D cn=config -H $URI1 -y $CONFIGPWF -bcn=config -E \!sync=rp >/dev/null 2>&1 RC=$? - touch $RCOUT + echo $RC > $RCOUT exit $RC ) & @@ -137,7 +137,7 @@ if test -f "$RCOUT" ; then wait $SEARCHPID - SEARCHRC=$? + SEARCHRC=`cat $RCOUT` echo "Checking return code of backgrounded RefreshAndPersist search ..." if test $SEARCHRC != 52 ; then echo "Error: Backgrounded ldapsearch did return the wrong error code: $SEARCHRC"

1 0

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

22 Jun '11

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: $ 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,"

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs