openldap-bugs September 2011

openldap-bugs@openldap.org

32 participants
59 discussions

RE: (ITS#7051) ldap_pvt_tls_get_peer_dn fails under gnutls
by Giampaolo＠Tomassoni.biz 30 Sep '11

30 Sep '11

> > This is the needed patch: > > This patch should not work either, you still need a skip_tag before the > get_int. > > > - tag = ber_skip_tag( ber,&len ); /* Context + > Constructed > > (version) */ > > + tag = ber_peek_tag( ber,&len ); /* Context + > Constructed I confirm this patch worked for me, at least it did on an amd64 I'm working on. It worked both with openssl-generated v1 (no version tag present) and v3 certificates (version tag present). I don't know if this is an cpu-architecture -dependent issue (I don't think so), nor I know how the ber_* library works, but FWICU the Context + Constructed stuff is handled as a tag prefix by the ber_get_int(), which then discards it when found and fetches the encapsulated value. Instead, ber_peek_tag() is probably more simple-minded in that it peeks the first word at the buffer pointer, which is the Context + Constructed prefix, not really the tag. I can of course be wrong, but with this patch I got i==2 from v3 certificates, which is the correct value. Giampaolo

1 0

Re: (ITS#6979) test062 portability
by h.b.furuseth＠usit.uio.no 30 Sep '11

30 Sep '11

Aaron Richton writes: > 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? I'm curious, what is this about - an observed bug, or not? There is no function call here, 'wait' is checking a subprocess's exit status. That's standard, and so is checking the return (not exit) status from a function as far as I know, but I'm not surprised if some shells have quirks. I noticed because I saw the patch entering master. Which is fine by me, except the patch may be a bit incomplete. Since $SEARCHRC is now the output from `cat`, it may be best to quote it here: > if test $SEARCHRC != 52 ; then -- Hallvard

1 0

Re: (ITS#7006) openldap does not accept wildcard certificates with mozilla/nss
by hyc＠symas.com 30 Sep '11

30 Sep '11

hash_oldap(a)cycdolphin.net wrote: > Full_Name: Philippe Kueck > Version: 2.4.23 / 2.4.26 > OS: RHEL 6.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.98.65.86) > > > When compiled against Mozilla/NSS OpenLDAP does not accept wildcard > certificates. > > This is probably because in tls_m.c the certificate CN (*.domain.example) is > matched against the hostname (foo.domain.example), not against the domain > (.domain.example). > > I suggest the following patch: Thanks for the report, fixed in master. > > --%snip%-- > diff -Nru openldap-2.4.26-orig/libraries/libldap/tls_m.c > openldap-2.4.26/libraries/libldap/tls_m.c > --- openldap-2.4.26-orig/libraries/libldap/tls_m.c 2011-06-30 17:13:36.000000000 > +0200 > +++ openldap-2.4.26/libraries/libldap/tls_m.c 2011-08-01 16:29:42.000000000 > +0200 > @@ -2590,7 +2590,7 @@ > if ( av->len == nlen&& !strncasecmp( name, (char *)av->data, nlen )) { > ret = LDAP_SUCCESS; > } else if ( av->data[0] == '*'&& av->data[1] == '.'&& > - domain&& dlen == av->len - 1&& !strncasecmp( name, > + domain&& dlen == av->len - 1&& !strncasecmp( domain, > (char *)(av->data+1), dlen )) { > ret = LDAP_SUCCESS; > } else { > --%snip%-- > > > Kind regards, > > Philippe Kueck > > -- -- 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#7011) signal 6 got in ldap_abandon
by hyc＠symas.com 30 Sep '11

30 Sep '11

ogermain(a)tibco.com wrote: > Full_Name: Olivier GERMAIN > Version: 2.4.24 > OS: Solaris 5.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.157.248.2) > > > Dear All, > > One of our customer got a signal 6 during the execution of the ldap_abandon. > This signal occurred whereas some maintenance was doing on a firewall which is > not located on the same network. It seems that the ldap_abandon thrown this > assert because it was a situation like a can't happen. I don't have much > information on the action performed on the firewall which led to this sigabort. > > > Please find the logs I have : > 2011-07-19 04:08:52.876909|ENG|FATAL|84|engine.cpp(109)| > /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/distrib/kabira/lib/libsyssrv.so:sw_debugSignalHandler+0x18 > 2011-07-19 04:08:52.877541|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:<static-func>+0x5b0 > 2011-07-19 04:08:52.878082|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:<static-func>+0x628 > 2011-07-19 04:08:52.878658|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:_lwp_kill+0x8 [ Signal 6 (SIGABRT) ] > 2011-07-19 04:08:52.879196|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:abort+0xd0 > 2011-07-19 04:08:52.879733|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:_assert+0x74 > 2011-07-19 04:08:52.880325|ENG|FATAL|84|engine.cpp(109)| > /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/3rdparty/sol/openldap/2.4.24_64/lib/libldap-2.4.so.2.6.0:<static-func>+0x4ec > 2011-07-19 04:08:52.880776|ENG|FATAL|84|engine.cpp(109)| > /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/3rdparty/sol/openldap/2.4.24_64/lib/libldap-2.4.so.2.6.0:ldap_abandon+0xac > > I am in the process of a reproduction of this signal 6 but I would like to share > the following idea. > > Do you think there is a possibility to enhance the openldap library to avoid > this assert? Is it possible that instead of having an assert, we have a > exception or a status code which tell us something went wrong of obviously that > we can handle in our source code. An assert means there is a bug, either in your code or ours. Since this part of the library has been around for several years with no issues, that generally means it's a bug in your code. The way to handle this is to fix your code. Trapping or ignoring the conditions that are asserted is just a bad idea. > > My best regards > Olivier GERMAIN > TIBCO Support team > > -- -- 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#7040) Out of sync consumer replicas after standby master takes over (MMR)
by Howard Chu 30 Sep '11

30 Sep '11

Thanks for the report. Now fixed in master.

1 0

Re: (ITS#7037) slapd crashes with syncrepl when replica cleared out DB
by hyc＠symas.com 30 Sep '11

30 Sep '11

ml+openldap(a)esmtp.org wrote: > Full_Name: Claus Assmann > Version: 2.4.26 > OS: Red Hat Enterprise Linux Server release 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.211.143.38) > > > While trying to determine how syncrepl behaves in various error > conditions, I encountered a crash of slapd. A MASTER is set up to > use push replication to a REPLICA as follows: > > database ldap > hidden on > suffix "" > rootdn "cn=slapd-ldap" > uri ldap://REPLICA/ > lastmod on > restrict all > sync_use_subentry true > > acl-bind bindmethod=simple > binddn="cn=Monitor" > credentials=password > > syncrepl rid=001 > provider=ldapi://%2Fvar%2Frun%2Fldapi > binddn="cn=Manager" > bindmethod=simple > credentials=passwd > searchbase="" > type=refreshAndPersist > retry="5 5 60 +" > > Reproduce: > On REPLICA: stop slapd, clear out directory for DB, start > slapd. > On MASTER: > add an entry master which has to be "synced" to REPLICA; > run ldapsearch to lookup up that entry on MASTER > slapd dumps core, backtrace: Thanks for the report. There were two bugs here: 1) the syncrepl_add_glue_ancestors was not constructing a valid DN for the empty-suffix case. 2) it shouldn't have tried to add glue entries in this case anyway, since the underlying DB was pulled out from under it. Both fixed now in master, please test. > #0 0x00002b7e51344265 in raise () from /lib64/libc.so.6 > #1 0x00002b7e51345d10 in abort () from /lib64/libc.so.6 > #2 0x00002b7e5133d6e6 in __assert_fail () from /lib64/libc.so.6 > #3 0x0000000000549546 in ldap_add_ext (ld=0xbba1bc0, dn=0x0, attrs=0xbeb7ed0, > sctrls=0x0, cctrls=0x0, msgidp=0x435224c4) at add.c:126 > #4 0x00000000004dbe6d in ldap_back_add (op=0x43523150, rs=0x43522770) > at add.c:102 > #5 0x0000000000481152 in overlay_op_walk (op=0x43523150, rs=0x43522770, > which=op_add, oi=0xb9eb6c0, on=0x0) at backover.c:671 > #6 0x00000000004816a7 in over_op_func (op=0x43523150, rs=0x43522770, > which=op_add) at backover.c:723 > #7 0x0000000000473706 in syncrepl_add_glue_ancestors (op=0x43523150, > e=0x2b7e56628fb8) at syncrepl.c:3149 > #8 0x000000000047384e in syncrepl_add_glue (op=0x43523150, e=0x2b7e56628fb8) > at syncrepl.c:3193 > #9 0x0000000000474795 in syncrepl_entry (si=0xb9eb1c0, op=0x43523150, > entry=0x0, modlist=0x43523ca0, syncstate=<value optimized out>, > syncUUID=<value optimized out>, syncCSN=0xbeb86e0) at syncrepl.c:2448 > #10 0x000000000047c39b in do_syncrep2 (ctx=<value optimized out>, > arg=<value optimized out>) at syncrepl.c:982 > #11 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) > at syncrepl.c:1489 > #12 0x000000000041eee3 in connection_read_thread (ctx=0x43523da0, > argv=<value optimized out>) at connection.c:1276 > #13 0x00000000005412dc in ldap_int_thread_pool_wrapper (xpool=0xb8fa1c0) > at tpool.c:685 > #14 0x00002b7e510ff73d in start_thread () from /lib64/libpthread.so.0 > #15 0x00002b7e513e84bd in clone () from /lib64/libc.so.6 > > Note: this also happens with 2.4.23. On a VM instance, it causes > a different error (see mail on list: "killed after 120 seconds") > > -- -- 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#7051) ldap_pvt_tls_get_peer_dn fails under gnutls
by hyc＠symas.com 30 Sep '11

30 Sep '11

giampaolo(a)tomassoni.biz wrote: > Full_Name: Giampaolo Tomassoni > Version: 2.4.24 > OS: Linux 2.6.39-gentoo-r3 > URL: > Submission from: (NULL) (79.23.61.128) > > > A triky mistake (is it a typo?) in libraries/libldap/tls_g.c:tlsg_x509_cert_dn > prevents a gnutls-enabled server to correctly obtain the "subject" ASN.1 tree > from the client's certificate. Thanks for the report, now fixed in master, please test. > > This is the needed patch: This patch should not work either, you still need a skip_tag before the get_int. > --- libraries/libldap/tls_g.c.wrong 2011-09-25 14:58:30.000000000 +0200 > +++ libraries/libldap/tls_g.c 2011-09-25 14:35:06.000000000 +0200 > @@ -530,7 +530,7 @@ > ber_init2( ber, cert, LBER_USE_DER ); > tag = ber_skip_tag( ber,&len ); /* Sequence */ > tag = ber_skip_tag( ber,&len ); /* Sequence */ > - tag = ber_skip_tag( ber,&len ); /* Context + Constructed > (version) */ > + tag = ber_peek_tag( ber,&len ); /* Context + Constructed > (version) */ > if ( tag == 0xa0 ) /* Version is optional */ > tag = ber_get_int( ber,&i ); /* Int: Version */ > tag = ber_skip_tag( ber,&len ); /* Int: Serial (can be longer > than ber_int_t) */ > > > Basically, the optional version field in the certificate wasn't peeked, but > rather skipped. This resulted in walking in the certificate tree in the wrong > way, thereby impairing a correct result from > libraries/libldap/tls2.c:ldap_pvt_tls_get_peer_dn. > > I'm not using sasl, so I can't be sure about this, but I guess this problem > could impair client authentication via certificate using the sasl external > method. > > -- -- 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#7052) Spurious CSNs being recorded on syncrepl consumers.
by hyc＠symas.com 30 Sep '11

30 Sep '11

cmikk(a)qwest.net wrote: > Full_Name: Chris Mikkelson > Version: 2.4.26 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (204.147.85.37) > > > When the provider sends a search response with state 'delete' with no / null > cookie, the syncrepl consumer queues an locally-generated CSN and updates its > context CSN with that. This appears to happen only with cookie-less deletion, > not with cookie-less modification. I have not observed a cookie-less addition, > so I do not know if it occurs there, too. Thanks for the report. The bug only affected Deletes, not add or modify. Fixed in master. > Example logs from a pure consumer (no server-id, replicating from a provider > with server id 002): > > Sep 26 13:05:42 mpls-auth-02 slapd[57295]: do_syncrep2: rid=100 cookie= > Sep 26 13:05:42 mpls-auth-02 slapd[57295]: syncrepl_entry: rid=100 > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_DELETE) > Sep 26 13:05:42 mpls-auth-02 slapd[57295]: syncrepl_entry: rid=100 be_search > (0) > Sep 26 13:05:42 mpls-auth-02 slapd[57295]: syncrepl_entry: rid=100 > uid=<snip>,ou=improv,dc=qwest,dc=net > Sep 26 13:05:42 mpls-auth-02 slapd[57295]: slap_queue_csn: queing 0x7ffffe3fa560 > 20110926130542.130924Z#000000#000#000000 > Sep 26 13:05:42 mpls-auth-02 slapd[57295]: slap_graduate_commit_csn: removing > 0x8f58a8a90 20110926130542.130924Z#000000#000#000000 > > This is problematic at our site because the provider cookie contains a SID 0 CSN > from before we migrated to multimaster, and the SID 0 CSN recorded at the > consumer renders the consumer state newer than the provider, breaking > replication. > > -- -- 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#7054) Please drop support to FreeBSD 1.x
by d＠delphij.net 28 Sep '11

28 Sep '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Kurt, On 09/28/11 18:26, Kurt Zeilenga wrote: > Given the project doesn't specifically attempt to support FreeBSD > 1.x, your request as summarized in the subject line is a bit odd. > > I suggest this be considered more of a request to enable future > support of the FreeBSD 10.x. > > Do the current release of libtool and autotools includes the > enabling features needed? > > If so, then this can simply be treated as a request to update these > tools (which are generally incorporated without any functional > change). > > If not, well, then we should just wait for thsoe enabling changes > to be released by the upstream tool provider first I think we will have to wait for upstream release then, the changes are already in their source tree. I'll patch OpenLDAP in the FreeBSD ports to make it work at this moment. > Regards, Kurt > > On Sep 28, 2011, at 2:38 PM, delphij(a)FreeBSD.org wrote: > >> Full_Name: Xin Li Version: git trunk OS: FreeBSD/amd64 10.1 URL: >> http://pastebin.com/G8gpJs0r Submission from: (NULL) >> (206.40.55.65) >> >> >> Code duplicated from GNU libtool and autotools uses 'freebsd1*' >> rather than 'freebsd1.*' to test if the system is FreeBSD 1.x. >> This logic would match FreeBSD 10.0, causing problem when >> building shared libraries. >> >> I'd like to propose that FreeBSD 1.x support be dropped since >> it's obsolete in 1994 (17 years ago). >> >> The patch is just for reference, it also drops FreeBSD 2.x and >> FreeBSD 3.x support but it's not complete. >> >> A libtool patched with git revision >> e94c6d6e0359d92f08f491f57e0ef3371e978952 would also be required >> to build OpenLDAP properly. >> > - -- Xin LI <delphij(a)delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOg87cAAoJEATO+BI/yjfBfwIIAIjdABO2EUPVNpGLRrOqt20I Yl5reH+OsBBwRTgjdDflZJcRA68fb5nsdsrRBheJA6oT0EJKWpPoW+uLjg84zx6s TvGAifKMDJv6+v/PHpTkv2wO7nYIKXiS6D9415cJk3xMdEcDdRSXi+ppA+6IXGzV fRL4rej0hoHNvgbXvowOL8F24rnnb6+r9fYYH773rwomL/+rYqZ1+iDbM4zs82d4 TSxOtjmfoEqUCyYJii3jo5CGs1LQ+Ndk16s7uwTArevba89GPVrNL3s/FxBLrEX+ Q8mBHaCkmsX1JuN7ZkYTJz7UvMJJO25IHDfEpjkM5aCqZvuy9nq7kflXxvuOASo= =Wmav -----END PGP SIGNATURE-----

1 0

Re: (ITS#7054) Please drop support to FreeBSD 1.x
by hyc＠symas.com 28 Sep '11

28 Sep '11

delphij(a)FreeBSD.org wrote: > Full_Name: Xin Li > Version: git trunk > OS: FreeBSD/amd64 10.1 > URL: http://pastebin.com/G8gpJs0r > Submission from: (NULL) (206.40.55.65) > > > Code duplicated from GNU libtool and autotools uses 'freebsd1*' rather than > 'freebsd1.*' to test if the system is FreeBSD 1.x. This logic would match > FreeBSD 10.0, causing problem when building shared libraries. > > I'd like to propose that FreeBSD 1.x support be dropped since it's obsolete in > 1994 (17 years ago). Probably a good idea. Thanks for the patch, but it's basically unusable. Never submit patches to generated files. Only patch the source files. configure is generated from configure.in by autoconf. aclocal.m4 is also generated by autoconf; the section you patched appears to come from the libtool sources. > The patch is just for reference, it also drops FreeBSD 2.x and FreeBSD 3.x > support but it's not complete. > > A libtool patched with git revision e94c6d6e0359d92f08f491f57e0ef3371e978952 > would also be required to build OpenLDAP properly. > > -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2011