- openldap-bugs - openldap.org

Re: (ITS#5601) set-acl failure under back-ldap+rwm
by ando＠sys-net.it 12 Jul '08

12 Jul '08

ando(a)sys-net.it wrote: > mbackes(a)symas.com wrote: > > The reason is quite simple: set expansion uses the rewritten DN as the > user's name, so a local lookup of the entry "cn=user,dc=remote" fails > since no local database serves the naming context "dc=remote". The root > cause is that back-ldap binds as the rewritten DN, which is later stored > as the real identity. I think this was done on purpose, and is to some > extent appropriate, but makes the type of ACL you want to design > basically impossible. A solution would be to make slapo-rwm intercept > successful binds (in the cleanup callback) and rewrite back the bound DN > into the virtual naming context. I'll see if it is possible, but then > we need to decide whether this is the desired behavior. Otherwise, we'd > need to have two o_ndn fields: the real DN and the real-real DN. To further elaborate, even if the virtual DN is set instead of the real one in c_ndn, the operation fails because ACL checking passes through bi_entry_get_rw(), which is not provided by slapo-rwm, and can't be provided according to the current design, since it does not allow to massage the arguments. As a quick'n'dirty fix, what you can do is make the proxy database serve both naming contexts, namely database ldap suffix "dc=remote,dc=local" suffix "dc=remote" uri "ldap://127.0.0.1:2389" acl-bind bindmethod=simple binddn="cn=user,dc=remote" credentials=secret overlay rwm rwm-suffixmassage "dc=remote,dc=local" "dc=remote" This allows the proxy database to be found by select_backend() when searching the right backend using the real naming context. At the same time, internal searches occur as expected. This is a hack; the real fix requires to redesign the API of bi_entry_get_rw(), to let it modify the request arguments while letting the real function do the hard job. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5601) set-acl failure under back-ldap+rwm
by ando＠sys-net.it 12 Jul '08

12 Jul '08

mbackes(a)symas.com wrote: The reason is quite simple: set expansion uses the rewritten DN as the user's name, so a local lookup of the entry "cn=user,dc=remote" fails since no local database serves the naming context "dc=remote". The root cause is that back-ldap binds as the rewritten DN, which is later stored as the real identity. I think this was done on purpose, and is to some extent appropriate, but makes the type of ACL you want to design basically impossible. A solution would be to make slapo-rwm intercept successful binds (in the cleanup callback) and rewrite back the bound DN into the virtual naming context. I'll see if it is possible, but then we need to decide whether this is the desired behavior. Otherwise, we'd need to have two o_ndn fields: the real DN and the real-real DN. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

ldapi:// SASL EXTERNAL on solaris10
by David Markey 11 Jul '08

11 Jul '08

Hi, I'm trying to implement heimdal with an LDAP backend on solaris 10 and im getting issues with authentication when initialising a realm: kadmin> init DMARKEY.COM kadmin: hdb_open: ldap_sasl_bind_s: Authentication method not supported __________________________ ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 send_ldap_result: err=7 matched="" text="SASL(-4): no mechanism available: " connection_get(12) ber_dump: buf=82c5408 ptr=82c5408 end=82c540d len=5 0000: 02 01 02 42 00 slapd.conf(snippet): sasl-secprops minssf=0 sasl-regexp .*uidNumber=0.*,cn=peercred, cn=external,cn=auth uid=heimdal,dc=services,dc=dmarkey,dc=com Would anyone be able to help me? Solaris 10 x86, Heimdal 1.0.2, slapd 2.3.39 I've established this is a solaris specific problem, i compiled everything from scratch on CentOS with the same options and it worked fine. Anyone have any ideas? are sockets different on solaris? Much appreciated.

2 1

Re: (ITS#5593) Back-meta search references
by quanah＠zimbra.com 10 Jul '08

10 Jul '08

--On Thursday, July 10, 2008 1:05 PM +0000 andrew.graham(a)agustawestland.com wrote: > *** Before acting on this email or opening any attachment you are > advised to read the disclaimer at the end of this email *** > > I patched the changes into 2.4.10 and it works perfectly. > > Will this make it into 2.4.11? Yes > If so what is the time frame for release? When we feel it is ready. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5593) Back-meta search references
by andrew.graham＠agustawestland.com 10 Jul '08

10 Jul '08

*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email *** I patched the changes into 2.4.10 and it works perfectly. Will this make it into 2.4.11? If so what is the time frame for release? Thanks for such a fast response! Drew Andrew Graham AgustaWestland UK andrew.graham(a)agustawestland.com >>> <ando(a)sys-net.it> 07/07/2008 20:27 >>> andrew.graham(a)agustawestland.com wrote: > Please provide an option to stop search references being proxied from target to > client in back-meta. "norefs yes" added to HEAD (default "no"). Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it ----------------------------------- *** Disclaimer *** The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s). For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If received in error please return to sender immediately. Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence. Westland Helicopters Ltd Lysander Road Yeovil BA20 2YB England Registered in England under No 604352

1 0

Re: (ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by ando＠sys-net.it 10 Jul '08

10 Jul '08

michael(a)stroeder.com wrote: > Kurt Zeilenga wrote: >> Declarations of schema elements should be published as specified in >> RFCs. [..] If caseIgnoreListMatch is not supported, than the >> MatchingRule definition for caseIgnoreListMatch should not be >> published. > > I suspected an answer like this. I've changed my code to also look up > whether the matching rule description itself exists but loose subschema > definitions like this makes it really hard to implement smarter > schema-aware clients. :-/ > > These kind of things would be interesting subjects of interop testing. > >> I note that the specification does allow publication of unimplemented >> descriptions. > > Even worse. :-( Aside from conformity of OpenLDAP's current behavior, I'd consider this ITS as a request to finally implement that matching rule. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by michael＠stroeder.com 10 Jul '08

10 Jul '08

Kurt Zeilenga wrote: > The definitions themselves, such as for postalAddress, should be > generally viewed as immutable. Additionally if a local configuration differs from a RFC you might consider this to be bad practice. But thinking this to the end a server MAY then apply another matching rule to a given attribute type but keep the attribute type description as defined in the RFC. That's even worse because the server behaves differently but the client won't be able to find out. Very bad! Ciao, Michael.

1 0

Re: (ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by michael＠stroeder.com 10 Jul '08

10 Jul '08

Kurt Zeilenga wrote: > Declarations of schema elements should be published as specified in > RFCs. [..] If caseIgnoreListMatch is not supported, than the > MatchingRule definition for caseIgnoreListMatch should not be > published. I suspected an answer like this. I've changed my code to also look up whether the matching rule description itself exists but loose subschema definitions like this makes it really hard to implement smarter schema-aware clients. :-/ These kind of things would be interesting subjects of interop testing. > I note that the specification does allow publication of unimplemented > descriptions. Even worse. :-( Ciao, Michael.

1 0

Re: (ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by Kurt＠OpenLDAP.org 10 Jul '08

10 Jul '08

Declarations of schema elements should be published as specified in RFCs. RFC 4512: Servers SHOULD provide definitions of all schema elements they support in subschema (sub)entries. The definitions themselves, such as for postalAddress, should be generally viewed as immutable. Only certain additions (alternative names and extensions can be added, and DESC values changed. Matching rules should never be changed. > If the equality matching rule is not implemented it should not be announced in the subschema. Assuming you mean that the "EQUALITY caseIgnoreListMatch" should be removed, no. If caseIgnoreListMatch is not supported, than the MatchingRule definition for caseIgnoreListMatch should not be published. > The server should not simply report what might have been defined in some RFC. No. See above. I note that the specification does allow publication of unimplemented descriptions. It actually legal to publish caseIgnoreListMatch. But OpenLDAP has traditionally only published supported descriptions.

1 0

(ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by michael＠stroeder.com 10 Jul '08

10 Jul '08

Full_Name: Michael Ströder Version: HEAD OS: OpenSUSE Linux 10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.78.239) Looking at the logs slapo-constraint seems to generate a filter which is considered bad by slapd: constraint_violation uri filter = (&((objectClass=organizationalUnit))(|(ou=Abteilung 1))) This filter would work and finds the correct entry containing the valid attribute value: (&(objectClass=organizationalUnit)(|(ou=Abteilung 1)))

1 0

Re: (ITS#5565) slapd crashes due to SIGPIPE
by quanah＠zimbra.com 09 Jul '08

09 Jul '08

--On Wednesday, July 09, 2008 1:18 PM +0000 jwm(a)horde.net wrote: > On Wed, Jul 09, 2008 at 09:48:52AM +0200, Buchan Milne wrote: >> On Saturday 21 June 2008 00:26:00 jwm(a)horde.net wrote: >> > On Fri, Jun 20, 2008 at 01:37:15PM -0700, Howard Chu wrote: >> > > > Program received signal SIGABRT, Aborted. >> > > > [Switching to Thread -1963996240 (LWP 22635)] >> > > > 0xb7bb1947 in raise () from /lib/tls/libc.so.6 >> > > >> > > This trace resembles ITS#5401, which was only fixed in RE24. You can >> > > look at the patch to syncprov.c there. There's no plan to make >> > > another 2.3 release at the moment. >> > >> > I don't mind patching for this locally, since slapd is crashing every >> > few days. I looked at the patch for ITS 5401 in RE24. I don't know >> > enough about slapd internals to easily backport it to RE23 since a fair >> > bit of the surrounding code differs between RE23 and RE24; would you be >> > willing to do >> >> The patches I found for this in RE24 seem to apply without problems on >> RE23. See attached patch its5401-re23.patch. >> >> Howard, this includes syncprov.c 1.219->1.220 and 1.147.2.27->1.147.2.28 >> (see attached its5401.patch), was that all? > > Heh, I totally glossed over 1.120 and went straight for 1.147.2.28; given > that the latter is on top of the former, it makes perfect sense now. :-/ This will be in 2.3.43. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4685) Updated changelog overlay by Neil Dunbar
by sebastian＠rieger.info 09 Jul '08

09 Jul '08

since we're still using the overlay to synchronize our identities between OpenLDAP and Active Directory using Novell Identity Manager, I made a little update again that keeps up with latest OpenLDAP development in HEAD and finally includes some documentation that was initially written by Neil Dunbar. Thanks to Paul Turgyan I was able to fix some memory leaks that occured in specific situations when base64 encoded attributes were changed. As requested I also tried to get conform to the IPR policies that are required when contributing to OpenLDAP. I know that the changelog mechanism as described in the draft draft-good-ldap-changelog-03 is not new fashion - but some large dirctory servers and identity management products seem to stick to this "standard". You can find the updated versions in: for OpenLDAP 2.3.x (tested up to 2.3.42): ftp://ftp.openldap.org/incoming/rieger-changelog-23-pkg-080706.tgz for OpenLDAP 2.4.x (tested up to HEAD): ftp://ftp.openldap.org/incoming/rieger-changelog-24-pkg-080706.tgz I'll be glad for any feedback, Sebastian

1 0

Re: (ITS#5565) slapd crashes due to SIGPIPE
by jwm＠horde.net 09 Jul '08

09 Jul '08

On Wed, Jul 09, 2008 at 09:48:52AM +0200, Buchan Milne wrote: > On Saturday 21 June 2008 00:26:00 jwm(a)horde.net wrote: > > On Fri, Jun 20, 2008 at 01:37:15PM -0700, Howard Chu wrote: > > > > Program received signal SIGABRT, Aborted. > > > > [Switching to Thread -1963996240 (LWP 22635)] > > > > 0xb7bb1947 in raise () from /lib/tls/libc.so.6 > > > > > > This trace resembles ITS#5401, which was only fixed in RE24. You can > > > look at the patch to syncprov.c there. There's no plan to make another > > > 2.3 release at the moment. > > > > I don't mind patching for this locally, since slapd is crashing every > > few days. I looked at the patch for ITS 5401 in RE24. I don't know > > enough about slapd internals to easily backport it to RE23 since a fair > > bit of the surrounding code differs between RE23 and RE24; would you be > > willing to do > > The patches I found for this in RE24 seem to apply without problems on > RE23. See attached patch its5401-re23.patch. > > Howard, this includes syncprov.c 1.219->1.220 and 1.147.2.27->1.147.2.28 > (see attached its5401.patch), was that all? Heh, I totally glossed over 1.120 and went straight for 1.147.2.28; given that the latter is on top of the former, it makes perfect sense now. :-/ Thanks, Buchan. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

(ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by michael＠stroeder.com 09 Jul '08

09 Jul '08

Full_Name: Michael Ströder Version: RE24 OS: OpenSUSE Linux 10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.107.210) Using OpenLDAP 2.4.10 (RE24) I'm trying to explicitly delete a value of attribute postalAddress: --------------------------------------------------------------- dn: cn=Fred Feuerstein,ou=Testing,dc=stroeder,dc=de changetype: modify delete: postalAddress postalAddress: zeile 1$zeile 2$zeile 3 - --------------------------------------------------------------- But this results in an error: modifying entry "cn=Fred Feuerstein,ou=Testing,dc=stroeder,dc=de" ldapmodify: Inappropriate matching (18) additional info: modify/delete: postalAddress: no equality matching rule But postalAddress is declared in the schema like this: ( 2.5.4.16 NAME 'postalAddress' DESC 'RFC2256: postal address' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) If the equality matching rule is not implemented it should not be announced in the subschema. The server should not simply report what might have been defined in some RFC. Ciao, Michael.

1 0

Re: (ITS#5565) slapd crashes due to SIGPIPE
by bgmilne＠staff.telkomsa.net 09 Jul '08

09 Jul '08

--Boundary-00=_k1GdIEk7s64l4zW Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Saturday 21 June 2008 00:26:00 jwm(a)horde.net wrote: > On Fri, Jun 20, 2008 at 01:37:15PM -0700, Howard Chu wrote: > > > Program received signal SIGABRT, Aborted. > > > [Switching to Thread -1963996240 (LWP 22635)] > > > 0xb7bb1947 in raise () from /lib/tls/libc.so.6 > > > > This trace resembles ITS#5401, which was only fixed in RE24. You can look > > at the patch to syncprov.c there. There's no plan to make another 2.3 > > release at the moment. > > I don't mind patching for this locally, since slapd is crashing every few > days. I looked at the patch for ITS 5401 in RE24. I don't know enough about > slapd internals to easily backport it to RE23 since a fair bit of the > surrounding code differs between RE23 and RE24; would you be willing to do The patches I found for this in RE24 seem to apply without problems on RE23. See attached patch its5401-re23.patch. Howard, this includes syncprov.c 1.219->1.220 and 1.147.2.27->1.147.2.28 (see attached its5401.patch), was that all? Regards, Buchan --Boundary-00=_k1GdIEk7s64l4zW Content-Type: text/x-diff; charset="utf-8"; name="its5401-re23.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its5401-re23.patch" Index: servers/slapd/overlays/syncprov.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/syncprov.c,v retrieving revision 1.56.2.50 diff -u -r1.56.2.50 syncprov.c --- servers/slapd/overlays/syncprov.c 14 May 2008 00:49:04 -0000 1.56.2.50 +++ servers/slapd/overlays/syncprov.c 9 Jul 2008 07:22:23 -0000 @@ -1840,12 +1840,10 @@ op2->o_do_not_cache = 1; /* Add op2 to conn so abandon will find us */ - ldap_pvt_thread_mutex_lock( &op->o_conn->c_mutex ); op->o_conn->c_n_ops_executing++; op->o_conn->c_n_ops_completed--; LDAP_STAILQ_INSERT_TAIL( &op->o_conn->c_ops, op2, o_next ); so->s_flags |= PS_IS_DETACHED; - ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); /* Prevent anyone else from trying to send a result for this op */ op->o_abandon = 1; @@ -1933,15 +1931,27 @@ /* Detach this Op from frontend control */ ldap_pvt_thread_mutex_lock( &ss->ss_so->s_mutex ); + ldap_pvt_thread_mutex_lock( &op->o_conn->c_mutex ); - /* Turn off the refreshing flag */ - ss->ss_so->s_flags ^= PS_IS_REFRESHING; + /* But not if this connection was closed along the way */ + if ( op->o_abandon ) { + ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); + ldap_pvt_thread_mutex_unlock( &ss->ss_so->s_mutex ); + /* syncprov_ab_cleanup will free this syncop */ + return SLAPD_ABANDON; - syncprov_detach_op( op, ss->ss_so, on ); + } else { + /* Turn off the refreshing flag */ + ss->ss_so->s_flags ^= PS_IS_REFRESHING; + + syncprov_detach_op( op, ss->ss_so, on ); - /* If there are queued responses, fire them off */ - if ( ss->ss_so->s_res ) - syncprov_qstart( ss->ss_so ); + ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); + + /* If there are queued responses, fire them off */ + if ( ss->ss_so->s_res ) + syncprov_qstart( ss->ss_so ); + } ldap_pvt_thread_mutex_unlock( &ss->ss_so->s_mutex ); return LDAP_SUCCESS; --Boundary-00=_k1GdIEk7s64l4zW Content-Type: text/x-diff; charset="utf-8"; name="its5401.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its5401.patch" --- servers/slapd/overlays/syncprov.c 2008/03/12 21:31:28 1.219 +++ servers/slapd/overlays/syncprov.c 2008/03/13 09:49:32 1.220 @@ -1,4 +1,4 @@ -/* $OpenLDAP: servers/slapd/overlays/syncprov.c,v 1.219 2008/03/12 21:31:28 ando Exp $ */ +/* $OpenLDAP: servers/slapd/overlays/syncprov.c,v 1.220 2008/03/13 09:49:32 hyc Exp $ */ /* syncprov.c - syncrepl provider */ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * @@ -1940,12 +1940,10 @@ op2->o_do_not_cache = 1; /* Add op2 to conn so abandon will find us */ - ldap_pvt_thread_mutex_lock( &op->o_conn->c_mutex ); op->o_conn->c_n_ops_executing++; op->o_conn->c_n_ops_completed--; LDAP_STAILQ_INSERT_TAIL( &op->o_conn->c_ops, op2, o_next ); so->s_flags |= PS_IS_DETACHED; - ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); /* Prevent anyone else from trying to send a result for this op */ op->o_abandon = 1; @@ -2055,15 +2053,27 @@ /* Detach this Op from frontend control */ ldap_pvt_thread_mutex_lock( &ss->ss_so->s_mutex ); + ldap_pvt_thread_mutex_lock( &op->o_conn->c_mutex ); - /* Turn off the refreshing flag */ - ss->ss_so->s_flags ^= PS_IS_REFRESHING; + /* But not if this connection was closed along the way */ + if ( op->o_abandon ) { + ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); + ldap_pvt_thread_mutex_unlock( &ss->ss_so->s_mutex ); + syncprov_free_syncop( ss->ss_so ); + return SLAPD_ABANDON; - syncprov_detach_op( op, ss->ss_so, on ); + } else { + /* Turn off the refreshing flag */ + ss->ss_so->s_flags ^= PS_IS_REFRESHING; + + syncprov_detach_op( op, ss->ss_so, on ); - /* If there are queued responses, fire them off */ - if ( ss->ss_so->s_res ) - syncprov_qstart( ss->ss_so ); + ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); + + /* If there are queued responses, fire them off */ + if ( ss->ss_so->s_res ) + syncprov_qstart( ss->ss_so ); + } ldap_pvt_thread_mutex_unlock( &ss->ss_so->s_mutex ); return LDAP_SUCCESS; diff -u -r1.147.2.27 -r1.147.2.28 --- servers/slapd/overlays/syncprov.c 2008/05/28 16:35:32 1.147.2.27 +++ servers/slapd/overlays/syncprov.c 2008/05/29 15:02:45 1.147.2.28 @@ -1,4 +1,4 @@ -/* $OpenLDAP: servers/slapd/overlays/syncprov.c,v 1.147.2.27 2008/05/28 16:35:32 quanah Exp $ */ +/* $OpenLDAP: servers/slapd/overlays/syncprov.c,v 1.147.2.28 2008/05/29 15:02:45 hyc Exp $ */ /* syncprov.c - syncrepl provider */ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * @@ -2107,7 +2107,7 @@ if ( op->o_abandon ) { ldap_pvt_thread_mutex_unlock( &op->o_conn->c_mutex ); ldap_pvt_thread_mutex_unlock( &ss->ss_so->s_mutex ); - syncprov_free_syncop( ss->ss_so ); + /* syncprov_ab_cleanup will free this syncop */ return SLAPD_ABANDON; } else { --Boundary-00=_k1GdIEk7s64l4zW--

1 0

Re: (ITS#5604) sbin executable names not recognised on Win32
by mail_ben_schmidt＠yahoo.com.au 09 Jul '08

09 Jul '08

Hallvard B Furuseth wrote: > Might be better to insert the following at the end of > libraries/liblutil/utils.c:lutil_progname(): > > #if <something> > { > size_t len = strlen( progname ); > if ( len > 4 && strcasecmp( progname + len - 4, ".exe" ) == 0 ) > progname[len - 4] = '\0'; > } > #endif > > I have no idea what the #if should be though. Does #ifdef _WIN32 still > work with cross-compilation? Yes, I think that's a neater solution. Having a runtime conditional avoids breaking Cygwin binaries that might not have .exe in progname, too. To be honest, I'm not sure whether the compiler/configure defines _WIN32 for cross compilation by default. I could easily find out, but to be honest, I don't think it's worth it: you pretty much have to ensure it's defined because there are many places in the source code it is used. Using it here as well seems smart. Cheers, Ben.

1 0

Re: (ITS#5604) sbin executable names not recognised on Win32
by hyc＠symas.com 09 Jul '08

09 Jul '08

h.b.furuseth(a)usit.uio.no wrote: > Might be better to insert the following at the end of > libraries/liblutil/utils.c:lutil_progname(): > > #if<something> > { > size_t len = strlen( progname ); > if ( len> 4&& strcasecmp( progname + len - 4, ".exe" ) == 0 ) > progname[len - 4] = '\0'; > } > #endif > > I have no idea what the #if should be though. Does #ifdef _WIN32 still > work with cross-compilation? > Yes. -- -- 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#5604) sbin executable names not recognised on Win32
by h.b.furuseth＠usit.uio.no 09 Jul '08

09 Jul '08

Might be better to insert the following at the end of libraries/liblutil/utils.c:lutil_progname(): #if <something> { size_t len = strlen( progname ); if ( len > 4 && strcasecmp( progname + len - 4, ".exe" ) == 0 ) progname[len - 4] = '\0'; } #endif I have no idea what the #if should be though. Does #ifdef _WIN32 still work with cross-compilation? -- Hallvard

1 0

(ITS#5607) Double close problem for SQL handles in back-sql
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

Full_Name: Ben Schmidt Version: 2.4.10 OS: MinGW32, Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.168.9.190) I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. I found two bugs in the source code relating to shutdown/freeing structures. This is the second. It relates to back-sql, which I realise is unsupported on this platform, but seems to work very nicely once this and another bugfix or two (my other posts) are made. Mind you, I have only done a small amount of testing, and don't really understand what I am doing, as I am a complete newbie to LDAP. After sending these patches I intend to embark on a reading of your Administrator's Guide to learn. >From the source code, though, I don't see why the problem would only apply to this platform anyway. It is this: When an SQL handle is opened, it is registered to be freed. When it is freed, however, it is not deregistered, so can easily be freed twice, particularly as to load the schemas the database connection is opened and closed. I suggest this patch to fix it (the patch looks larger than it really is as some code needed to be moved to ensure correct definition order): diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/back-sql/sql-wrap.c openldap/servers/slapd/back-sql/sql-wrap.c --- openldap-2.4.10/servers/slapd/back-sql/sql-wrap.c 2008-02-12 10:26:48.000000000 +1100 +++ openldap/servers/slapd/back-sql/sql-wrap.c 2008-06-28 22:29:25.000000000 +1000 @@ -462,28 +462,31 @@ return LDAP_SUCCESS; } +static void *backsql_db_conn_dummy; + +static void +backsql_db_conn_keyfree( + void *key, + void *data ) +{ + backsql_close_db_handle( (SQLHDBC)data ); +} + int backsql_free_db_conn( Operation *op, SQLHDBC dbh ) { Debug( LDAP_DEBUG_TRACE, "==>backsql_free_db_conn()\n", 0, 0, 0 ); (void)backsql_close_db_handle( dbh ); + ldap_pvt_thread_pool_setkey( op->o_threadctx, + &backsql_db_conn_dummy, (void *)SQL_NULL_HDBC, + backsql_db_conn_keyfree, NULL, NULL ); Debug( LDAP_DEBUG_TRACE, "<==backsql_free_db_conn()\n", 0, 0, 0 ); return LDAP_SUCCESS; } -static void *backsql_db_conn_dummy; - -static void -backsql_db_conn_keyfree( - void *key, - void *data ) -{ - backsql_close_db_handle( (SQLHDBC)data ); -} - int backsql_get_db_conn( Operation *op, SQLHDBC *dbhp ) { I could not find this issue already in your tracker.

1 0

(ITS#5606) Attempt to close unopened sockets when daemon doesn't run as a daemon
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

Full_Name: Ben Schmidt Version: 2.4.10 OS: MinGW32, Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.168.9.190) I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. I found two bugs in the source code relating to shutdown/freeing structures. This is the first. Because slapd_daemon_destroy can be called without slapd_deamon_init being called (e.g. if testing configuration, or giving -VV as the documentation suggests does something, though I'm not sure what), an attempt can be made to close sockets not opened. I suggest the following fix: diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/daemon.c openldap/servers/slapd/daemon.c --- openldap-2.4.10/servers/slapd/daemon.c 2008-05-28 06:12:44.000000000 +1000 +++ openldap/servers/slapd/daemon.c 2008-06-28 21:54:38.000000000 +1000 @@ -79,7 +79,7 @@ #define SLAPD_LISTEN_BACKLOG 1024 #endif /* ! SLAPD_LISTEN_BACKLOG */ -static ber_socket_t wake_sds[2]; +static ber_socket_t wake_sds[2] = {INVALID_SOCKET, INVALID_SOCKET}; static int emfile; static volatile int waking; @@ -1641,8 +1643,10 @@ slapd_daemon_destroy( void ) { connections_destroy(); - tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); - tcp_close( SLAP_FD2SOCK(wake_sds[0]) ); + if ( wake_sds[1] != INVALID_SOCKET ) + tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); + if ( wake_sds[0] != INVALID_SOCKET ) + tcp_close( SLAP_FD2SOCK(wake_sds[0]) ); sockdestroy(); #ifdef HAVE_SLP I couldn't find this mentioned in your tracker already.

1 0

(ITS#5605) Inappropriate SLAP_SOCK_NOT_ACTIVE assertion failing
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

Full_Name: Ben Schmidt Version: 2.4.10 OS: MinGW32, Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.168.9.190) I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. While debugging to find and fix two crashes which I will detail in other posts, I discovered that an assertion is always failing because it seems it is inappropriately included when it shouldn't be. I suggest this patch. diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/daemon.c openldap/servers/slapd/daemon.c --- openldap-2.4.10/servers/slapd/daemon.c 2008-05-28 06:12:44.000000000 +1000 +++ openldap/servers/slapd/daemon.c 2008-06-28 21:54:38.000000000 +1000 @@ -829,7 +829,9 @@ { ldap_pvt_thread_mutex_lock( &slap_daemon.sd_mutex ); +#if defined(HAVE_EPOLL) assert( SLAP_SOCK_NOT_ACTIVE(s) ); +#endif if ( isactive ) slap_daemon.sd_nactives++; If you search for where the relevant parts of the macros involved in SLAP_SOCK_NOT_ACTIVE, and particularly the marking of active and inactive, I believe you will find they apply only in the HAVE_EPOLL case, and thus the assertion should only hold in that case. I did find a closed issue in your tracker related to the same assertion failing, but it didn't detail the fix, and was very old, so I assume was not relevant to this particular problem.

1 0

(ITS#5604) sbin executable names not recognised on Win32
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

Full_Name: Ben Schmidt Version: 2.4.10 OS: MinGW32, Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.168.9.190) I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. In so doing, I discovered the following platform-specific issue. The executables on Win32 have a .exe extension, so slapd does not detect the tool names and act accordingly. Consequently, slapadd, slaptest, etc. all act the same as slapd! I solved the problem by patching main.c as follows: diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/main.c openldap/servers/slapd/main.c --- openldap-2.4.10/servers/slapd/main.c 2008-05-20 10:10:40.000000000 +1000 +++ openldap/servers/slapd/main.c 2008-06-28 21:56:09.000000000 +1000 @@ -71,14 +71,14 @@ char *name; MainFunc *func; } tools[] = { - {"slapadd", slapadd}, - {"slapcat", slapcat}, - {"slapdn", slapdn}, - {"slapindex", slapindex}, - {"slappasswd", slappasswd}, - {"slaptest", slaptest}, - {"slapauth", slapauth}, - {"slapacl", slapacl}, + {"slapadd.exe", slapadd}, + {"slapcat.exe", slapcat}, + {"slapdn.exe", slapdn}, + {"slapindex.exe", slapindex}, + {"slappasswd.exe", slappasswd}, + {"slaptest.exe", slaptest}, + {"slapauth.exe", slapauth}, + {"slapacl.exe", slapacl}, /* NOTE: new tools must be added in chronological order, * not in alphabetical order, because for backwards * compatibility name[4] is used to identify the Obviously this exact fix is not appropriate, because it will break every other platform, but I am not sure of the appropriate preprocessor directive to use to address this, as I guess it would also break a cygwin build, and should only be done for a MinGW32 build. However, it would be helpful to fix with an appropriate conditional! I couldn't find a mention of this in your tracker so reporting it now.

1 0

(ITS#5603) Linking OpenSSL on Windows requires libgdi32 and libws2_32 after libcrypto
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

Full_Name: Ben Schmidt Version: 2.4.10 OS: MinGW32, Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.168.9.190) My precise situation is, I am sure, a very uncommon scenario. However, it may affect other building methods as well, and an appropriate fix I am sure could help a few users. Here's what I have been doing (please try not to laugh!): I have been cross-compiling OpenLDAP on Mac OS X for MinGW32, including the SQL backend. I have found two issues related to the configuration/build process. I am afraid I really have no knowledge of GNU autoconf, so I will describe the problem and my fixes, but with no pretense that they are appropriate for applying to the code. I will suggest an appropriate way to fix it, but will have to leave that work to another developer. This is the second. When linking OpenSSL on Windows, it is also necessary to link against libgdi32 and libws2_32 needs to be linked after libcrypto. I worked around the problem with a simple substitution in configure: s/-lcrypto/-lcrypto -lgdi32 -lws2_32 A more appropriate fix would be to make configure test first without these extra libraries, and then with them, so that they are included if needed. Note that configure will not fail if -lws2_32 is omitted, but building libldap and libldap_r will fail later. I think it is probably safe to assume that if -lgdi32 is needed, -lws2_32 will be (or at least available and not harmful to include). A quick search and I couldn't find this issue already in your tracker.

1 0

(ITS#5602) Windows ODBC library libodbc32 not found by configure
by mail_ben_schmidt＠yahoo.com.au 08 Jul '08

08 Jul '08

Full_Name: Ben Schmidt Version: 2.4.10 OS: MinGW32, Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.168.9.190) My precise situation is, I am sure, a very uncommon scenario. However, it may affect other building methods as well, and an appropriate fix I am sure could help a few users. Here's what I have been doing (please try not to laugh!): I have been cross-compiling OpenLDAP on Mac OS X for MinGW32, including the SQL backend. I have found two issues related to the configuration/build process. I am afraid I really have no knowledge of GNU autoconf, so I will describe the problem and my fixes, but with no pretense that they are appropriate for applying to the code. I will suggest an appropriate way to fix it, but will have to leave that work to another developer. This is the first. On Windows/MinGW, the ODBC library is not libodbc.a, but libodbc32.a. Furthermore, it seems the way function names are mangled on that platform includes their stack frame size: the symbol for SQLDriverConnect which configure tests for is _SQLDriverConnect@32. I got around this by manually changing -lodbc to -lodbc32 in configure and then further patching it as follows: diff -ru --exclude=Makefile openldap-2.4.10/configure openldap/configure --- openldap-2.4.10/configure 2008-02-12 10:36:45.000000000 +1100 +++ openldap/configure 2008-06-28 19:36:36.000000000 +1000 @@ -32018,11 +32018,14 @@ #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ -char SQLDriverConnect (); +/*char SQLDriverConnect ();*/ +#include <windows.h> +#include <sqlext.h> int main () { -SQLDriverConnect (); +/*SQLDriverConnect ();*/ +SQLDriverConnect (0,0,0,0,0,0,0,0); ; return 0; } This pulls in the appropriate headers for configure to find and use _SQLDriverConect@32 in libodbc32. I got part of the idea from another user's post I found on the Net, but a quick search of your issue tracker didn't show it up, so I am reporting it now. A more appropriate fix would be to change configure.in so that there are three checks for ODBC: one in libiodbc, one in libodbc and one in libodbc32, which is Windows specific, pulling in windows.h and sqlext.h before looking for the symbol with 8 arguments. I guess this would probably involve a more customised macro in configure.in. If that is too much trouble, perhaps the value for the ODBC library could just be assumed if configure can detect a Windows build.

1 0

A bunch of bugs the ITS seems to be ignoring
by Ben Schmidt 08 Jul '08

08 Jul '08

Hi, In late June I tried to submit 6 bug reports using your issue tracker online. They seemed to submit OK, but didn't show up straight away, however since you note on the site that they may not show up immediately, I was content to wait. They still haven't shown up, though. So now I have 7 bug reports! The original six are below. The seventh is that the issue tracker doesn't work, or requires login or something else that isn't documented. If someone knows what I was doing wrong with the tracker and can explain what I should be doing, I'm happy to enter these into it again more effectively. (My email program is likely to wrap this and thereby botch up the patches, too. They're probably still easy enough to understand/fix.) Ben. ------------------------------------------------------------------------ My precise situation is, I am sure, a very uncommon scenario. However, it may affect other building methods as well, and an appropriate fix I am sure could help a few users. Here's what I have been doing (please try not to laugh!): I have been cross-compiling OpenLDAP on Mac OS X for MinGW32, including the SQL backend. I have found two issues related to the configuration/build process. I am afraid I really have no knowledge of GNU autoconf, so I will describe the problem and my fixes, but with no pretense that they are appropriate for applying to the code. I will suggest an appropriate way to fix it, but will have to leave that work to another developer. This is the first. On Windows/MinGW, the ODBC library is not libodbc.a, but libodbc32.a. Furthermore, it seems the way function names are mangled on that platform includes their stack frame size: the symbol for SQLDriverConnect which configure tests for is _SQLDriverConnect@32. I got around this by manually changing -lodbc to -lodbc32 in configure and then further patching it as follows: diff -ru --exclude=Makefile openldap-2.4.10/configure openldap/configure --- openldap-2.4.10/configure 2008-02-12 10:36:45.000000000 +1100 +++ openldap/configure 2008-06-28 19:36:36.000000000 +1000 @@ -32018,11 +32018,14 @@ #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ -char SQLDriverConnect (); +/*char SQLDriverConnect ();*/ +#include <windows.h> +#include <sqlext.h> int main () { -SQLDriverConnect (); +/*SQLDriverConnect ();*/ +SQLDriverConnect (0,0,0,0,0,0,0,0); ; return 0; } This pulls in the appropriate headers for configure to find and use _SQLDriverConect@32 in libodbc32. I got part of the idea from another user's post I found on the Net, but a quick search of your issue tracker didn't show it up, so I am reporting it now. A more appropriate fix would be to change configure.in so that there are three checks for ODBC: one in libiodbc, one in libodbc and one in libodbc32, which is Windows specific, pulling in windows.h and sqlext.h before looking for the symbol with 8 arguments. I guess this would probably involve a more customised macro in configure.in. If that is too much trouble, perhaps the value for the ODBC library could just be assumed if configure can detect a Windows build. ------------------------------------------------------------------------ My precise situation is, I am sure, a very uncommon scenario. However, it may affect other building methods as well, and an appropriate fix I am sure could help a few users. Here's what I have been doing (please try not to laugh!): I have been cross-compiling OpenLDAP on Mac OS X for MinGW32, including the SQL backend. I have found two issues related to the configuration/build process. I am afraid I really have no knowledge of GNU autoconf, so I will describe the problem and my fixes, but with no pretense that they are appropriate for applying to the code. I will suggest an appropriate way to fix it, but will have to leave that work to another developer. This is the second. When linking OpenSSL on Windows, it is also necessary to link against libgdi32 and libws2_32 needs to be linked after libcrypto. I worked around the problem with a simple substitution in configure: s/-lcrypto/-lcrypto -lgdi32 -lws2_32 A more appropriate fix would be to make configure test first without these extra libraries, and then with them, so that they are included if needed. Note that configure will not fail if -lws2_32 is omitted, but building libldap and libldap_r will fail later. I think it is probably safe to assume that if -lgdi32 is needed, -lws2_32 will be (or at least available and not harmful to include). A quick search and I couldn't find this issue already in your tracker. ------------------------------------------------------------------------ I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. In so doing, I discovered the following platform-specific issue. The executables on Win32 have a .exe extension, so slapd does not detect the tool names and act accordingly. Consequently, slapadd, slaptest, etc. all act the same as slapd! I solved the problem by patching main.c as follows: diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/main.c openldap/servers/slapd/main.c --- openldap-2.4.10/servers/slapd/main.c 2008-05-20 10:10:40.000000000 +1000 +++ openldap/servers/slapd/main.c 2008-06-28 21:56:09.000000000 +1000 @@ -71,14 +71,14 @@ char *name; MainFunc *func; } tools[] = { - {"slapadd", slapadd}, - {"slapcat", slapcat}, - {"slapdn", slapdn}, - {"slapindex", slapindex}, - {"slappasswd", slappasswd}, - {"slaptest", slaptest}, - {"slapauth", slapauth}, - {"slapacl", slapacl}, + {"slapadd.exe", slapadd}, + {"slapcat.exe", slapcat}, + {"slapdn.exe", slapdn}, + {"slapindex.exe", slapindex}, + {"slappasswd.exe", slappasswd}, + {"slaptest.exe", slaptest}, + {"slapauth.exe", slapauth}, + {"slapacl.exe", slapacl}, /* NOTE: new tools must be added in chronological order, * not in alphabetical order, because for backwards * compatibility name[4] is used to identify the Obviously this exact fix is not appropriate, because it will break every other platform, but I am not sure of the appropriate preprocessor directive to use to address this, as I guess it would also break a cygwin build, and should only be done for a MinGW32 build. However, it would be helpful to fix with an appropriate conditional! I couldn't find a mention of this in your tracker so reporting it now. ------------------------------------------------------------------------ I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. While debugging to find and fix two crashes which I will detail in other posts, I discovered that an assertion is always failing because it seems it is inappropriately included when it shouldn't be. I suggest this patch. diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/daemon.c openldap/servers/slapd/daemon.c --- openldap-2.4.10/servers/slapd/daemon.c 2008-05-28 06:12:44.000000000 +1000 +++ openldap/servers/slapd/daemon.c 2008-06-28 21:54:38.000000000 +1000 @@ -829,7 +829,9 @@ { ldap_pvt_thread_mutex_lock( &slap_daemon.sd_mutex ); +#if defined(HAVE_EPOLL) assert( SLAP_SOCK_NOT_ACTIVE(s) ); +#endif if ( isactive ) slap_daemon.sd_nactives++; If you search for where the relevant parts of the macros involved in SLAP_SOCK_NOT_ACTIVE, and particularly the marking of active and inactive, I believe you will find they apply only in the HAVE_EPOLL case, and thus the assertion should only hold in that case. I did find a closed issue in your tracker related to the same assertion failing, but it didn't detail the fix, and was very old, so I assume was not relevant to this particular problem. ------------------------------------------------------------------------ I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. I found two bugs in the source code relating to shutdown/freeing structures. This is the first. Because slapd_daemon_destroy can be called without slapd_deamon_init being called (e.g. if testing configuration, or giving -VV as the documentation suggests does something, though I'm not sure what), an attempt can be made to close sockets not opened. I suggest the following fix: diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/daemon.c openldap/servers/slapd/daemon.c --- openldap-2.4.10/servers/slapd/daemon.c 2008-05-28 06:12:44.000000000 +1000 +++ openldap/servers/slapd/daemon.c 2008-06-28 21:54:38.000000000 +1000 @@ -79,7 +79,7 @@ #define SLAPD_LISTEN_BACKLOG 1024 #endif /* ! SLAPD_LISTEN_BACKLOG */ -static ber_socket_t wake_sds[2]; +static ber_socket_t wake_sds[2] = {INVALID_SOCKET, INVALID_SOCKET}; static int emfile; static volatile int waking; @@ -1641,8 +1643,10 @@ slapd_daemon_destroy( void ) { connections_destroy(); - tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); - tcp_close( SLAP_FD2SOCK(wake_sds[0]) ); + if ( wake_sds[1] != INVALID_SOCKET ) + tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); + if ( wake_sds[0] != INVALID_SOCKET ) + tcp_close( SLAP_FD2SOCK(wake_sds[0]) ); sockdestroy(); #ifdef HAVE_SLP I couldn't find this mentioned in your tracker already. ------------------------------------------------------------------------ I have recently cross-compiled OpenLDAP for MinGW32 on Mac OS X. I found two bugs in the source code relating to shutdown/freeing structures. This is the second. It relates to back-sql, which I realise is unsupported on this platform, but seems to work very nicely once this and another bugfix or two (my other posts) are made. Mind you, I have only done a small amount of testing, and don't really understand what I am doing, as I am a complete newbie to LDAP. After sending these patches I intend to embark on a reading of your Administrator's Guide to learn. From the source code, though, I don't see why the problem would only apply to this platform anyway. It is this: When an SQL handle is opened, it is registered to be freed. When it is freed, however, it is not deregistered, so can easily be freed twice, particularly as to load the schemas the database connection is opened and closed. I suggest this patch to fix it (the patch looks larger than it really is as some code needed to be moved to ensure correct definition order): diff -ru --exclude=Makefile openldap-2.4.10/servers/slapd/back-sql/sql-wrap.c openldap/servers/slapd/back-sql/sql-wrap.c --- openldap-2.4.10/servers/slapd/back-sql/sql-wrap.c 2008-02-12 10:26:48.000000000 +1100 +++ openldap/servers/slapd/back-sql/sql-wrap.c 2008-06-28 22:29:25.000000000 +1000 @@ -462,28 +462,31 @@ return LDAP_SUCCESS; } +static void *backsql_db_conn_dummy; + +static void +backsql_db_conn_keyfree( + void *key, + void *data ) +{ + backsql_close_db_handle( (SQLHDBC)data ); +} + int backsql_free_db_conn( Operation *op, SQLHDBC dbh ) { Debug( LDAP_DEBUG_TRACE, "==>backsql_free_db_conn()\n", 0, 0, 0 ); (void)backsql_close_db_handle( dbh ); + ldap_pvt_thread_pool_setkey( op->o_threadctx, + &backsql_db_conn_dummy, (void *)SQL_NULL_HDBC, + backsql_db_conn_keyfree, NULL, NULL ); Debug( LDAP_DEBUG_TRACE, "<==backsql_free_db_conn()\n", 0, 0, 0 ); return LDAP_SUCCESS; } -static void *backsql_db_conn_dummy; - -static void -backsql_db_conn_keyfree( - void *key, - void *data ) -{ - backsql_close_db_handle( (SQLHDBC)data ); -} - int backsql_get_db_conn( Operation *op, SQLHDBC *dbhp ) { I could not find this issue already in your tracker. ------------------------------------------------------------------------

2 1

Re: (ITS#5569) smbk5pwd breaks ppolicy-mandated password changes
by bgmilne＠staff.telkomsa.net 08 Jul '08

08 Jul '08

On Tuesday 08 July 2008 11:55:19 Howard Chu wrote: > bgmilne(a)staff.telkomsa.net wrote: > > Full_Name: Buchan Milne > > Version: 2.3.41 > > OS: Linux 2.6 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (196.207.32.38) > > > > I have not run this same test case on 2.4.x yet, but I remember having > > problems trying to change passwords on 2.4.10 with a very similar > > configuration, so I think it exists in 2.4.10 as well. > > Please try this patch... Seems to fix it: [root@tiger ~]# ldappasswd -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -S New password: Re-enter new password: Enter LDAP Password: Result: Insufficient access (50) Additional info: Operations are restricted to bind/unbind/abandon/StartTLS/modify password [root@tiger ~]# urpmi openldap-servers To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "bgmilne") lib64ldap2.4_2 2.4.10 1.1mdv2008.1 x86_64 openldap 2.4.10 1.1mdv2008.1 x86_64 openldap-servers 2.4.10 1.1mdv2008.1 x86_64 9.5KB of additional disk space will be used. 1.5MB of packages will be retrieved. Proceed with the installation of the 3 packages? (Y/n) y installing lib64ldap2.4_2-2.4.10-1.1mdv2008.1.x86_64.rpm openldap-2.4.10-1.1mdv2008.1.x86_64.rpm openldap-servers-2.4.10-1.1mdv2008.1.x86_64.rpm from //home/bgmilne/rpm/mdk/RPMS.mdv2008.1/x86_64 Preparing... ############################################# 1/3: lib64ldap2.4_2 ############################################# 2/3: openldap ############################################# 3/3: openldap-servers ############################################# Stopping slapd: [ OK ] Starting slapd (ldap + ldaps): [ OK ] [root@tiger ~]# ldappasswd -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -S New password: Re-enter new password: Enter LDAP Password: [root@tiger ~]# Thanks, Buchan

1 0

Re: (ITS#5569) smbk5pwd breaks ppolicy-mandated password changes
by hyc＠symas.com 08 Jul '08

08 Jul '08

This is a multi-part message in MIME format. --------------020700010705000602080304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: 2.3.41 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.207.32.38) > I have not run this same test case on 2.4.x yet, but I remember having problems > trying to change passwords on 2.4.10 with a very similar configuration, so I > think it exists in 2.4.10 as well. Please try this patch... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------020700010705000602080304 Content-Type: text/plain; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dif.txt" Index: ppolicy.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/ppolicy.c,v retrieving revision 1.115 diff -u -r1.115 ppolicy.c --- ppolicy.c 12 Jun 2008 19:12:35 -0000 1.115 +++ ppolicy.c 8 Jul 2008 09:55:17 -0000 @@ -1401,7 +1401,7 @@ Attribute *pa, *ha, at; const char *txt; pw_hist *tl = NULL, *p; - int zapReset, send_ctrl = 0; + int zapReset, send_ctrl = 0, pwexop = 0; Entry *e; struct berval newpw = BER_BVNULL, oldpw = BER_BVNULL, *bv, cr[2]; @@ -1526,6 +1526,7 @@ req_pwdexop_s *qpw = sc->sc_private; newpw = qpw->rs_new; oldpw = qpw->rs_old; + pwexop = 1; break; } } @@ -1581,7 +1582,7 @@ } } - } else if ( !is_at_operational( ml->sml_desc->ad_type ) ) { + } else if ( !pwexop && !is_at_operational( ml->sml_desc->ad_type ) ) { mod_pw_only = 0; /* modifying something other than password */ } --------------020700010705000602080304--

1 0

Re: (ITS#5599) slapd dies on erroneous MOD input
by hasler＠ayni.com 08 Jul '08

08 Jul '08

Further to my report, i found the following in the syslog of when slapd had failed: Jul 7 07:05:31 myhost kernel: slapd[23962]: segfault at 0 ip 004cb118 sp b2b7c55c error 4 in libc-2.8.so[456000+163000] -- ---------------------------------------- Ayni AG Sternenstrasse 24 P.O.Box 1521 CH-8027 Zurich Switzerland, Europe +41 44 280 22 44, Fax +41 44 280 22 49 E-mail: nospam(a)ayni.com Web: http://www.ayni.com

1 0

(ITS#5601) set-acl failure under back-ldap+rwm
by mbackes＠symas.com 08 Jul '08

08 Jul '08

Full_Name: Matthew Backes Version: 2.3, 2.4 OS: all URL: Submission from: (NULL) (76.88.99.93) Set-acl who-clauses fail to match when accessing data through back-ldap and slapo-rwm. Given a local server with only the object: dn: cn=data,dc=local objectClass: organizationalPerson cn: data sn: sn data description: user where sn is an example attribute that we will protect: database bdb suffix "cn=data,dc=local" directory ./local checkpoint 1024 1 cachesize 10 index objectClass,dc,entryCSN,entryUUID eq index cn,sn,ou,title,description eq,sub access to dn.subtree="cn=data,dc=local" attrs=sn by set="user/title & this/description" write by * none access to dn.subtree="cn=data,dc=local" by * read So that any bound object with a title attribute matching the description attribute of the target should be able to see sn. Remote data: dn: dc=remote objectClass: organization objectClass: dcObject o: remote dc: remote dn: cn=user,dc=remote objectClass: organizationalPerson cn: user sn: user title: user userPassword: secret If we have the local slapd's back-ldap configured as: database ldap suffix "dc=remote" uri "ldap://127.0.0.1:2389" acl-bind bindmethod=simple binddn="cn=user,dc=remote" credentials=secret then everything works correctly. But if we remap the DN using slapo-rwm instead: database ldap suffix "dc=remote,dc=local" uri "ldap://127.0.0.1:2389" acl-bind bindmethod=simple binddn="cn=user,dc=remote" credentials=secret overlay rwm rwm-suffixmassage "dc=remote,dc=local" "dc=remote" Then the acl step fails: => access_allowed: read access to "cn=data,dc=local" "sn" requested => dn: [1] cn=data,dc=local => acl_get: [1] matched => acl_get: [1] attr sn access_allowed: no res from state (sn) => acl_mask: access to entry "cn=data,dc=local", attr "sn" requested => acl_mask: to value by "cn=user,dc=remote", (=0) <= check a_set_pat: user/title & this/description <= check a_dn_pat: * <= acl_mask: [2] applying none(=0) (stop) <= acl_mask: [2] mask: none(=0) => access_allowed: read access denied by none(=0) send_search_entry: conn 1 access to attribute sn, value #0 not allowed And the remote server was never queried for the title attribute.

1 0

Re: (ITS#5600) syncrepl modify fails if superior objectClass added
by hyc＠symas.com 07 Jul '08

07 Jul '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: linux and solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl fails to update an entry if the objectClass was replaced > with a new set of values that explicitly lists a superior that > was only implicitly present in the old entry. > > I have only seen this during the present phase of replication, so > I don't know if it can happen during persistent update as well. > It probably worked for me in the persistent phase as the entire > entry was deleted and added again there. > > The patch at the end always uses replace instead of delete/add > of the objectClass values. Is this OK Howard? Or is it > necessary to perform further analysis of which values to > add/delete? It's probably OK. Doing specific add/delete is better from an indexing performance point of view. ... ITS#5517 is really starting to annoy me ... > > Rein Tollevik > Basefarm AS > > Index: syncrepl.c > =================================================================== > RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/syncrepl.c,v > retrieving revision 1.1.1.31 > diff -u -u -r1.1.1.31 syncrepl.c > --- syncrepl.c 6 Jul 2008 12:23:53 -0000 1.1.1.31 > +++ syncrepl.c 7 Jul 2008 19:21:57 -0000 > @@ -2883,6 +2883,14 @@ > } > } > > + /* Don't delete/add an objectClass, always use the replace op. > + * Modify would fail if provider has replaced entry with a new, > + * and the new explicitly includes a superior of a class that was > + * only included implicitly in the old entry. Ref ITS#5517. > + */ > + if ( nn&& no< o&& old->a_desc == slap_schema.si_ad_objectClass ) > + no = o; > + > i = j; > /* all old values were deleted, just use the replace op */ > if ( no == o ) { > > > -- -- 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#5600) syncrepl modify fails if superior objectClass added
by rein＠OpenLDAP.org 07 Jul '08

07 Jul '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Syncrepl fails to update an entry if the objectClass was replaced with a new set of values that explicitly lists a superior that was only implicitly present in the old entry. I have only seen this during the present phase of replication, so I don't know if it can happen during persistent update as well. It probably worked for me in the persistent phase as the entire entry was deleted and added again there. The patch at the end always uses replace instead of delete/add of the objectClass values. Is this OK Howard? Or is it necessary to perform further analysis of which values to add/delete? Rein Tollevik Basefarm AS Index: syncrepl.c =================================================================== RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/syncrepl.c,v retrieving revision 1.1.1.31 diff -u -u -r1.1.1.31 syncrepl.c --- syncrepl.c 6 Jul 2008 12:23:53 -0000 1.1.1.31 +++ syncrepl.c 7 Jul 2008 19:21:57 -0000 @@ -2883,6 +2883,14 @@ } } + /* Don't delete/add an objectClass, always use the replace op. + * Modify would fail if provider has replaced entry with a new, + * and the new explicitly includes a superior of a class that was + * only included implicitly in the old entry. Ref ITS#5517. + */ + if ( nn && no < o && old->a_desc == slap_schema.si_ad_objectClass ) + no = o; + i = j; /* all old values were deleted, just use the replace op */ if ( no == o ) {

1 0

Re: (ITS#5580) BER Decoding Remote DoS Vulnerability
by quanah＠zimbra.com 07 Jul '08

07 Jul '08

--On Friday, June 27, 2008 12:41 AM +0000 hyc(a)symas.com wrote: > Howard Chu wrote: >> zdi-disclosures(a)tippingpoint.com wrote: >>> Full_Name: Cameron Hotchkies >>> Version: 2.3.41 >>> OS: Gentoo Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (66.179.208.36) >>> >>> >>> This vulnerability allows remote attackers to deny services on >>> vulnerable installations of OpenLDAP. Authentication is not required to >>> exploit this vulnerability. >> >> Thanks for the report, a fix is now in HEAD. Please test. > > For future reference, it looks like this may have crept in in 2001, rev > 1.88/ITS#2465... 2003, not 2001? 1.88 Thu Apr 24 00:10:18 2003 UTC; 5 years, 2 months ago by hyc Changed since 1.87: +3 -3 lines Diffs to 1.87 (colored diff) ITS#2465 fix? ber_get_next must read at least sizeof(tag)+sizeof(len) which should be at most 8 bytes. However if we read more than the minimum message length, we have a problem because we steal bytes from any following message, and there is no buffer mechanism to push back excess data. The shortest legitimate message is Unbind at 7 bytes, but there shouldn't be anything following it. Abandon at 8 bytes is next, so always requesting at least 8 bytes should be safe. Always requesting 9 was a problem. Please double-check these assumptions... -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5355) back-meta calls back-ldap directly
by ando＠sys-net.it 07 Jul '08

07 Jul '08

rein(a)OpenLDAP.org wrote: > After fetching the recent CVS head today I started getting spurious > failures in test036-meta-concurrency, which appears to be related to the > mod* test programs failing with this message: > > Administrative limit exceeded (11) Operation timed out > > I assume that the new "idle-timeout" directive in > tests/data/slapd-meta.conf is the root of the failures. I'm currently > testing with the value increased from 10 to 100, but I don't know what > the best value would be. So far so good, but too early to conclude.. Yes. I have the same impression. In fact, removing idle-timeout seems to cure the occasional failures. I'll probably have a deeper look into it next weekend. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5593) Back-meta search references
by ando＠sys-net.it 07 Jul '08

07 Jul '08

andrew.graham(a)agustawestland.com wrote: > Please provide an option to stop search references being proxied from target to > client in back-meta. "norefs yes" added to HEAD (default "no"). Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5594) assertion thrown in daemon.c
by quanah＠zimbra.com 07 Jul '08

07 Jul '08

--On Thursday, July 03, 2008 5:43 PM +0000 richton(a)nbcs.rutgers.edu wrote: > This of course has ITS#5489 written all over it. If there is another RE23, > consider this a request to include the appropriate patch. Done. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5599) slapd dies on erroneous MOD input
by suomi＠ayni.com 07 Jul '08

07 Jul '08

Full_Name: suomi hasler Version: 2.4.8-3 OS: fedora 9 URL: http://www.ayni.com/slap-prob.txt Submission from: (NULL) (194.158.243.162) use perl-LDAP-0.34-4.fc9.noarch to communicate with the ldap server bind to the cn=config subtree in this configuration, change this entry: dn="olcDatabase={-1}frontend,cn=config" which is an olcAccess with the original value of: {10}to dn.subtree="ou=postfix,dc=mydom,dc=com" by dn.base="cn=myname,ou=pam-ldap,dc=mydom,dc=com" write by dn.base="cn=postfix,ou=postfix,dc=mydom,dc=com" read by self write by anonymous auth by users none to the following (erroneous) value (note the missing opening brace at the start) 10}to dn.subtree="ou=postfix,dc=mydom,dc=com" by dn.base="cn=myname,ou=pam-ldap,dc=mydom,dc=com" write by dn.base="cn=postfix,ou=postfix,dc=mydom,dc=com" read by self write by anonymous auth by users none on the interface you get: <snip> Modifying Attributes of DN: olcDatabase={-1}frontend,cn=config Modify-Result-Code: 80 Modify Attribute Error: ResultCode: 80, ErrorMessage: <olcAccess> handler exited with 1 Return Code from Modify Attribute: 80 Message: LDAP_OTHER: An unknown error has occurred MessageID: 4 </snip> some seconds later, slapd fails, that is, it does not reply to requests any more, and must be stopped using kill -9 pid. thereafter, the db is garbled but can be recovered by slapd -d255 -uldap after that you may start slapd using the normal procedures: /etc/init.d/ldap start reproduceability: always

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 07 Jul '08

07 Jul '08

Hi, On Tue, Jun 24, 2008 at 12:50 PM, Sean Burford <unix.gurus(a)gmail.com> wrote: > namingContexts was the trickiest, since RFC 4512 defines it without an > equality matching rule but monitor_back_register_database() compares > it with backend suffixes. It has to deal with capitalised values > properly otherwise we end up with duplicate namingContexts entries, so > normalization is required. I have uploaded ftp://ftp.openldap.org/incoming/sean-burford-monitor-test-080706.patch which adds a test for various things under cn=monitor. If duplicate namingContexts creep in (as mentioned above) it detects that. The duplicate naming contexts thing was fixed by comparing a_vals with be_suffix, I just wrote the test since there was no existing cn=monitor test. -- Thanks, Sean Burford

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 07 Jul '08

07 Jul '08

Hi, On Sat, Jun 28, 2008 at 7:47 PM, Howard Chu <hyc(a)symas.com> wrote: > Howard Chu wrote: >> unix.gurus(a)gmail.com wrote: >>> If someone wants to accept or comment on what needs fixing in the >>> patch below, that would help me to generate the rest of the patches: >>> >>> ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-unified-0806… >> >> In back-monitor/database.c you don't need to normalize the DNs before >> comparing them. The stored values are already Prettied, so all you need is >> to >> use a case-insensitive compare here. > > Duh. Or just compare a->a_vals and be->be_suffix instead. Good point. I've uploaded the following patch which does that as well as adding matching rules to configContext and monitorContext: ftp://ftp.openldap.org/sean-burford-monitor-normalize-unified-080706.patch This patch should make the handling of normalization within cn=monitor consistent. -- Thanks, Sean Burford

1 0

Re: (ITS#5572) Append global ACL to new backends
by hyc＠symas.com 06 Jul '08

06 Jul '08

rein(a)OpenLDAP.org wrote: > rein(a)OpenLDAP.org skrev: >> Howard Chu wrote: >>> rein(a)OpenLDAP.org wrote: >>>> The global ACLs are not added to newly created backends, i.e a server >>>> restart >>>> must be done before they are included. The patch at the end should >>>> fix this. OK >>>> to commit Howard? >>> My preference here would be to rip out everything that appends the >>> global ACLs and instead change the access_allowed checker to reference >>> the global ACLs directly when needed. >> Agreed, that would also fix the problem that dynamic updates to the >> global ACLs requires a restart to be effective. I can look into this >> next week. To be sure I have the semantics correct, it should be to >> evalutate ALCs local to the backend first, then the global, until a >> matching entry has been found? > > I have finally had time to look at this, and I have uploaded a > suggestion for a patch to ftp://ftp.openldap.org/incoming/ITS5572.patch, > > The AccessControlState cache and its backtracking was complicating > things a bit, but I hope I have got it correct. All the tests succeed > with the patch, although I'm not sure whether the cache is actually > tested or not.. This looks OK to me, but Ando should probably have a look as well. > I haven't done anything with the code that avoids messing with the > global ACL part when modifications are done to a backend ACL, it will > simply not find any trailing frontend ACL to stay away from. I'll remove that code after this is committed. > There is a probably a similar problem in the pcache and translucent > overlays, as they makes a copy of the backend ACL when initializing. > I.e changes to the backend ACL would not be noticed until a restart? I > haven't look any further into this, but a bi_access_allowed function > that dynamically fetches the be_acl from the backend could be a fix. Hm... Have to re-think how this is handled. There are other backend parameters being copied as well. -- -- 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#5572) Append global ACL to new backends
by rein＠OpenLDAP.org 06 Jul '08

06 Jul '08

rein(a)OpenLDAP.org skrev: > Howard Chu wrote: >> rein(a)OpenLDAP.org wrote: >>> The global ACLs are not added to newly created backends, i.e a server >>> restart >>> must be done before they are included. The patch at the end should >>> fix this. OK >>> to commit Howard? >> My preference here would be to rip out everything that appends the >> global ACLs and instead change the access_allowed checker to reference >> the global ACLs directly when needed. > > Agreed, that would also fix the problem that dynamic updates to the > global ACLs requires a restart to be effective. I can look into this > next week. To be sure I have the semantics correct, it should be to > evalutate ALCs local to the backend first, then the global, until a > matching entry has been found? I have finally had time to look at this, and I have uploaded a suggestion for a patch to ftp://ftp.openldap.org/incoming/ITS5572.patch, The AccessControlState cache and its backtracking was complicating things a bit, but I hope I have got it correct. All the tests succeed with the patch, although I'm not sure whether the cache is actually tested or not.. I haven't done anything with the code that avoids messing with the global ACL part when modifications are done to a backend ACL, it will simply not find any trailing frontend ACL to stay away from. There is a probably a similar problem in the pcache and translucent overlays, as they makes a copy of the backend ACL when initializing. I.e changes to the backend ACL would not be noticed until a restart? I haven't look any further into this, but a bi_access_allowed function that dynamically fetches the be_acl from the backend could be a fix. Rein

1 0

Re: (ITS#5578) sortvals error
by hyc＠symas.com 05 Jul '08

05 Jul '08

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.10 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/andrew-findlay-20080625.tgz > Submission from: (NULL) (88.97.25.132) > > > When 'sortvals members' is in effect, some attribute modify operations produce > bad results. This seems to occur when an operation adds an attribute that sorts > to the end of the list. > > The attached tarball contains a cut-down config and dataset, along with a set of > scripts and LDIF files that demonstrate the bug. Thanks for the report. Seems the search routine wasn't copied correctly from back-bdb/idl.c. Fixed now in HEAD. -- -- 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#5598) issue 4068, test018-syncreplication-persist failed
by dimytch＠mail.ru 05 Jul '08

05 Jul '08

Full_Name: Dimitri Pekarovsky Version: 2.4.10 OS: Slackware Linux 12.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.26.128.251) logs and other (possibly) useful info are there: wisdom.org.ua/config.log.bz2 (23 KB) wisdom.org.ua/config.status.bz2 (16 KB) wisdom.org.ua/openldap-2.4.10-compiled-failed_test_018.tar.bz2 (9.1 MB) full dir More shortly: $ uname -a Linux fserv 2.6.24.4 #13 SMP Fri Mar 28 20:53:03 EET 2008 i686 Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz GenuineIntel GNU/Linux $ ./configure --prefix=/opt/ldap --sysconfdir=/etc --localstatedir=/var/ldap --disable-ipv6 --enable-syslog --enable-slapd --enable-cleartext --enable-crypt --enable-lmpasswd --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups --enable-slapi --enable-wrappers --enable-bdb=mod --enable-dnssrv=mod --enable-hdb=mod --enable-ldap=mod --enable-monitor=mod --enable-passwd=mod --enable-perl=mod --enable-relay=mod --enable-sock=mod --enable-overlays=mod --with-cyrus-sasl --with-threads --with-tls=openssl --enable-syncprov=mod --enable-seqmod=mod && make depend && make && make test ======VARIABLES $ echo $CFLAGS -msse2 -mcpu=pentium4 -mtune=pentium4 -pipe -I/opt/db/include -I/opt/ldap/include -I/opt/pgsql/include -I/opt/apache/include -I/opt/pgsql/include -I/opt/svn/include -L/opt/db/lib -L/opt/ldap/lib -L/opt/pgsql/lib -L/opt/pgsql/lib -L/opt/apache/lib -L/opt/svn/lib $ echo $CPPFLAGS -I/opt/db/include -I/opt/ldap/include -I/opt/pgsql/include -I/opt/apache/include -I/opt/pgsql/include -I/opt/svn/include $ echo $LDFLAGS -L/opt/db/lib -L/opt/ldap/lib -L/opt/pgsql/lib -L/opt/pgsql/lib -L/opt/apache/lib -L/opt/svn/lib .... Berkley DB 4.6.21 ....ERROR MESSAGE >>>>> Starting test018-syncreplication-persist ... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entry in the producer... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that producer slapd is running... Using ldapmodify to modify producer directory... Using ldappasswd to change some passwords... Waiting 15 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 25 seconds for syncrepl to receive changes... Try updating the consumer slapd... ldapmodify failed (255)! ./scripts/test018-syncreplication-persist: line 309: kill: (12453) - Нет такого процесса -- NO SUCH PROCESS (TRANSLATION ADDED BY HAND) >>>>> ./scripts/test018-syncreplication-persist failed (exit 255) make[2]: *** [bdb-mod] Ошибка 255 make[2]: Leaving directory `/usr/src/i/openldap-2.4.10/tests' make[1]: *** [test] Ошибка 2 make[1]: Leaving directory `/usr/src/i/openldap-2.4.10/tests' make: *** [test] Ошибка 2

1 0

Re: (ITS#5597) syncrepl can fail to compare CSN from provider
by hyc＠symas.com 05 Jul '08

05 Jul '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: linux, solaris > URL: > Submission from: (NULL) (84.215.36.97) > Submitted by: rein > > > If the syncrepl provider presents the same (or a lower) number of contextCSN > values than the consumer has, but with other sid values, it can fail to update > its values. > This is mostly seen in a multiple masters (as opposed to a multi-master) > configuration. > > The patch at the end should fix that. Does it look OK Howard? Yes, looks fine, go ahead and commit. > > Rein Tollevik > Basefarm AS > > Index: syncrepl.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/syncrepl.c,v > retrieving revision 1.405 > diff -u -u -r1.405 syncrepl.c > --- syncrepl.c 4 Jul 2008 21:44:39 -0000 1.405 > +++ syncrepl.c 4 Jul 2008 21:48:13 -0000 > @@ -689,8 +689,8 @@ > return -1; > } > > - for (i=0; i<sc1->numcsns; i++) { > - for (j=0; j<sc2->numcsns; j++) { > + for (j=0; j<sc2->numcsns; j++) { > + for (i=0; i<sc1->numcsns; i++) { > if ( sc1->sids[i] != sc2->sids[j] ) > continue; > value_match(&match, slap_schema.si_ad_entryCSN, > @@ -703,6 +703,11 @@ > } > break; > } > + if ( i == sc1->numcsns ) { > + /* sc2 has a sid sc1 lacks */ > + *which = j; > + return -1; > + } > } > return match; > } > > > -- -- 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#5597) syncrepl can fail to compare CSN from provider
by rein＠OpenLDAP.org 04 Jul '08

04 Jul '08

Full_Name: Rein Tollevik Version: CVS head OS: linux, solaris URL: Submission from: (NULL) (84.215.36.97) Submitted by: rein If the syncrepl provider presents the same (or a lower) number of contextCSN values than the consumer has, but with other sid values, it can fail to update its values. This is mostly seen in a multiple masters (as opposed to a multi-master) configuration. The patch at the end should fix that. Does it look OK Howard? Rein Tollevik Basefarm AS Index: syncrepl.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/syncrepl.c,v retrieving revision 1.405 diff -u -u -r1.405 syncrepl.c --- syncrepl.c 4 Jul 2008 21:44:39 -0000 1.405 +++ syncrepl.c 4 Jul 2008 21:48:13 -0000 @@ -689,8 +689,8 @@ return -1; } - for (i=0; i<sc1->numcsns; i++) { - for (j=0; j<sc2->numcsns; j++) { + for (j=0; j<sc2->numcsns; j++) { + for (i=0; i<sc1->numcsns; i++) { if ( sc1->sids[i] != sc2->sids[j] ) continue; value_match( &match, slap_schema.si_ad_entryCSN, @@ -703,6 +703,11 @@ } break; } + if ( i == sc1->numcsns ) { + /* sc2 has a sid sc1 lacks */ + *which = j; + return -1; + } } return match; }

1 0

Re: (ITS#5595) bdb deadlock if add causes modify
by hyc＠symas.com 04 Jul '08

04 Jul '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: linux and solaris > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > A deadlock occur in bdb_cache_modify() when it calls bdb_cache_entry_db_relock() > if adding an entry triggers a modify of the same entry. Seen by adding the > suffix entry of a backend with the syncprov overlay and syncprov-checkpoint set > to "1 1", i.e the add causes syncprov_checkpoint() to be called. > The problem is that bdb_add() calls send_ldap_result() while the entry is > locked. But I'm not sure whether releasing the entry before it is done is > correct or not. Nor if this should be considered a usage bug in the first > place... Yes, known issue, don't do this. -- -- 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#5596) contextCSN updates are internal operations
by hyc＠symas.com 04 Jul '08

04 Jul '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: linux, solaris > URL: > Submission from: (NULL) (84.215.36.97) > Submitted by: rein > > > syncrepl_updateCookie() doesn't initialize mod.sml_flags, which means that the > contextCSN modification is done with a random value. Which again can cause the > modify to fail if syncrepl is used on a subordinate DB with another rootdn than > what the glue DB has. As documented, glued DBs must all have the same rootDN. Any other configuration is a user error. > syncprov_checkpoint() has a similar problem, it initializes mod.sml_flags to 0. > When a checkpoint occur the modify operation is run with the privileges of what > might be in op->o_ndn. Checkpoint when the database is closed always works > though, as op->o_ndn is always set to the rootdn when that is done. > I'll commit a fix that sets mod.sml_flags to SLAP_MOD_INTERNAL shortly, so that > access control rules are bypassed. > > Rein Tollevik > Basefarm AS -- -- 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#5596) contextCSN updates are internal operations
by rein＠OpenLDAP.org 04 Jul '08

04 Jul '08

Full_Name: Rein Tollevik Version: CVS head OS: linux, solaris URL: Submission from: (NULL) (84.215.36.97) Submitted by: rein syncrepl_updateCookie() doesn't initialize mod.sml_flags, which means that the contextCSN modification is done with a random value. Which again can cause the modify to fail if syncrepl is used on a subordinate DB with another rootdn than what the glue DB has. syncprov_checkpoint() has a similar problem, it initializes mod.sml_flags to 0. When a checkpoint occur the modify operation is run with the privileges of what might be in op->o_ndn. Checkpoint when the database is closed always works though, as op->o_ndn is always set to the rootdn when that is done. I'll commit a fix that sets mod.sml_flags to SLAP_MOD_INTERNAL shortly, so that access control rules are bypassed. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5355) back-meta calls back-ldap directly
by rein＠OpenLDAP.org 04 Jul '08

04 Jul '08

After fetching the recent CVS head today I started getting spurious failures in test036-meta-concurrency, which appears to be related to the mod* test programs failing with this message: Administrative limit exceeded (11) Operation timed out I assume that the new "idle-timeout" directive in tests/data/slapd-meta.conf is the root of the failures. I'm currently testing with the value increased from 10 to 100, but I don't know what the best value would be. So far so good, but too early to conclude.. Rein

1 0

(ITS#5595) bdb deadlock if add causes modify
by rein＠OpenLDAP.org 04 Jul '08

04 Jul '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein A deadlock occur in bdb_cache_modify() when it calls bdb_cache_entry_db_relock() if adding an entry triggers a modify of the same entry. Seen by adding the suffix entry of a backend with the syncprov overlay and syncprov-checkpoint set to "1 1", i.e the add causes syncprov_checkpoint() to be called. The problem is that bdb_add() calls send_ldap_result() while the entry is locked. But I'm not sure whether releasing the entry before it is done is correct or not. Nor if this should be considered a usage bug in the first place... Rein Tollevik Basefarm AS

1 0

(ITS#5594) assertion thrown in daemon.c
by richton＠nbcs.rutgers.edu 03 Jul '08

03 Jul '08

Full_Name: Aaron Richton Version: 2.3.41 OS: Solaris 9 URL: http://www.openldap.org/its/index.cgi/Software Bugs?id=5489 Submission from: (NULL) (128.6.31.135) 2.3.41 died on one of my slaves: Current function is slapd_clr_write 813 assert( SLAP_SOCK_IS_ACTIVE( s )); (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff517fd810, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x44, 0x0, 0x44, 0x7efefeff, 0x81010100, 0xff0000), at 0xffffffff7f03e688 [4] __assert(0x1002394d8, 0x1002394f8, 0x32d, 0xffffffff517fca10, 0x1003afb60, 0x5), at 0xffffffff7f03e98c =>[5] slapd_clr_write(s = 180, wake = 0), line 813 in "daemon.c" [6] connection_write(s = 180), line 1905 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2329 in "daemon.c" The last log message related to this was: conn=65083139 fd=180 closed (connection lost on write) This of course has ITS#5489 written all over it. If there is another RE23, consider this a request to include the appropriate patch.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs