- openldap-bugs - openldap.org

(ITS#5273) ldap.conf and TLS as a default
by cardoe＠gentoo.org 12 Dec '07

12 Dec '07

Full_Name: Douglas Klima Version: 2.3. OS: Linux URL: Submission from: (NULL) (216.155.111.10) I was looking for a way to make TLS the default in /etc/openldap/ldap.conf however it currently seems impossible. You can specify LDAP over clear text and LDAP over SSL but you can't specify LDAP over TLS (I'm talking about "start_tls"). It seems like ldaps:// is deprecated in favor of ldap:// + TLS, which is why I'm trying to configure this. Currently my /etc/openldap/ldap.conf looks like: BASE dc=example,dc=com URI ldap://srv1.example.com ldap://srv2.example.com TLS_REQCERT demand TLS_CACERTDIR /etc/ssl/certs If I do the following: $ ldapsearch ldap_bind: Confidentiality required (13) additional info: TLS confidentiality required If I change URI to have "ldaps://srv1.example.com:389", then $ ldapsearch just hangs until it times out. Clearly it's not using start_tls. Now if I change URI back to it's original setting and do: $ ldapsearch -Z .... # search result search: 3 result: 0 Success # numResponses: 54 # numEntries: 53 I get a successful lookup. I'm basically looking for a way to pass "-Z" in /etc/openldap/ldap.conf and in .ldaprc Initially I tried to send this to the OpenLDAP ML but was told by MacJobBz to submit this to ITS.

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by hyc＠symas.com 11 Dec '07

11 Dec '07

Andrew Bartlett wrote: > On Tue, 2007-12-11 at 14:22 -0800, Howard Chu wrote: >> Andrew Bartlett wrote: >>> I wonder if there is a known issue with db 4.6 and OpenLDAP, as Fedora's >>> OpenLDAP seems to include it's own libslapd_db-4.4.so (it has a >>> slapd_db_stat to match, for 4.4). >> I think they packaged that to avoid using BDB 4.3 which was known to be >> broken. I've been using OpenLDAP with BDB 4.6.1 thru 4.6.3, and 4.6.18 thru >> 4.6.21 without any trouble. > > Where there any further clues on my deadlock in the db_stat output? Yes, it showed a transaction waiting for a write lock on an object that was held by a non-transactional reader. Normally that sort of thing should never deadlock. I would have to dig with gdb to identify which threads owned the locks in question. I guess I may have to build your source to try to duplicate the problem, unless you're up for walking thru a debug session thru IM/etc. -- -- Howard Chu Chief Architect, 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#5261) Samba4 can 'hang' OpenLDAP slapd
by abartlet＠samba.org 11 Dec '07

11 Dec '07

--=-5OIFeVOYW+hUABHuhQBa Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-12-11 at 14:22 -0800, Howard Chu wrote: > Andrew Bartlett wrote: > > I wonder if there is a known issue with db 4.6 and OpenLDAP, as Fedora'= s > > OpenLDAP seems to include it's own libslapd_db-4.4.so (it has a > > slapd_db_stat to match, for 4.4). >=20 > I think they packaged that to avoid using BDB 4.3 which was known to be=20 > broken. I've been using OpenLDAP with BDB 4.6.1 thru 4.6.3, and 4.6.18 th= ru=20 > 4.6.21 without any trouble. Where there any further clues on my deadlock in the db_stat output? Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-5OIFeVOYW+hUABHuhQBa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHXw8iz4A8Wyi0NrsRAsqOAJ44WnvMZZCXxu3KWaXpG80h98a9RQCfby5v h3+M0ny5D6JqcytP+00anRs= =huku -----END PGP SIGNATURE----- --=-5OIFeVOYW+hUABHuhQBa--

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by hyc＠symas.com 11 Dec '07

11 Dec '07

Andrew Bartlett wrote: > I wonder if there is a known issue with db 4.6 and OpenLDAP, as Fedora's > OpenLDAP seems to include it's own libslapd_db-4.4.so (it has a > slapd_db_stat to match, for 4.4). I think they packaged that to avoid using BDB 4.3 which was known to be broken. I've been using OpenLDAP with BDB 4.6.1 thru 4.6.3, and 4.6.18 thru 4.6.21 without any trouble. -- -- Howard Chu Chief Architect, 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#5265) back-ldif flunks test004-modify
by h.b.furuseth＠usit.uio.no 11 Dec '07

11 Dec '07

Pierangelo Masarati writes: >> test017-syncreplication-refresh > > works for me (in HEAD) For me too. Likely you fixed it with ldapdelete. However now HEAD run -b ldif test011-glue-slapadd fails with differently sorted entries: cn=Manager,dc=example,dc=com is out of place. >> test025-limits [didn't bump into server-side unchecked limit] > > no notion of "unckecked" (should walk the tree to find out how many > entries are there...) Or backends could count down from sizelimit.unchecked while examining and returning entries/referrals. Then fail with adminLimitExceeded if they reach zero. Is it OK to return entries followed by adminLimitExceeded? I don't see any protest in the LDAP RFCs, but I remember vaguely that the code may be mimicing X.500 errors which should not be combined with result entries. (I'll need to reread X.500 soon, it's been too long...) -- Regards, Hallvard

1 0

Re: (ITS#5265) back-ldif flunks test004-modify
by ando＠sys-net.it 11 Dec '07

11 Dec '07

h.b.furuseth(a)usit.uio.no wrote: test004 & test008: fixed (incorrect handling of file deletion) > While I'm checking this - other tests that fail with back-ldif: > test027-emptydn [cannot slapadd to a database with suffix ""] fixed > Unsupported operations, I guess: > test016-subref todo > test017-syncreplication-refresh works for me (in HEAD) > test025-limits [didn't bump into server-side unchecked limit] no notion of "unckecked" (should walk the tree to find out how many entries are there...) > test037-manage manage not supported > OK failure - compare fails because of entry order from ldapsearch: > test012-glue-populate todo > test026-dn fixed (search results not sorted by DN, thus insertion order not preserved by fs) > test004, test008 and test017 succeed in 2.3.38. Maybe the fix to > ITS#4627 (back-ldif issues) was bad? > 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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5272) facsimileNumber matching rules status
by ando＠sys-net.it 11 Dec '07

11 Dec '07

anders(a)anduras.de wrote: > I'm filing this new bug report, because I cannot add the question to the real > issue with number 2571 (it's always "Rejected; blocked by automated review > system"). Just send a message to openldap-its(a)openldap.org with ITS#2571 in the subject. > > So, take a look at: > http://www.openldap.org/its/index.cgi/Contrib?id=2571 > > My questions are: > > - What is the current status of this issue / patch? > (I want to see it supported as soon as possible.) Just edit the schema files, adding the desired matching rules. > - What does "Await IETF action" mean?? Presumably, there's an action open with IETF about modifying that schema item. As soon as it's officially modified, OpenLDAP will modify the schema files accordingly. In the meanwhile, all we can do is release schema files that comply with the current standard. This ITS will be closed. 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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5272) facsimileNumber matching rules status
by anders＠anduras.de 11 Dec '07

11 Dec '07

Full_Name: Sven Anders Version: 2.3.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.145.248.173) Hello! I'm filing this new bug report, because I cannot add the question to the real issue with number 2571 (it's always "Rejected; blocked by automated review system"). So, take a look at: http://www.openldap.org/its/index.cgi/Contrib?id=2571 My questions are: - What is the current status of this issue / patch? (I want to see it supported as soon as possible.) - What does "Await IETF action" mean?? Regards S.

1 0

(ITS#5271) size limit by ip (feature request)
by phr2101＠columbia.edu 10 Dec '07

10 Dec '07

Full_Name: Patrick Radtke Version: 2.3.24 OS: RHEL4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.145.98.209) The limits 'who' clause should be extended to allow control by ip address. Pierangelo Masarati said "Your problem sounds general enough to deserve an extension of the limits "who" clause semantics (I don't see it quite high-priority, though). In any case, the modification should be trivial enough. I suggest you file an ITS for a feature request." in response to my problem > Basically we have software running on a host that is > unable to authenticate (due to 3rd party software) > and we need to increase the size limits for queries coming from it, > without increasing that limit for all anonymous binds.

1 0

(ITS#5270) admin24/replication.html spelling
by msporleder＠gmail.com 10 Dec '07

10 Dec '07

Full_Name: Matthew Sporleder Version: 2.4 OS: netbsd URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.248.74.254) Try accepted here: As long as one Master is operational, writes can safely be excepted

1 0

Re: (ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by michael＠stroeder.com 09 Dec '07

09 Dec '07

Pierangelo Masarati wrote: >> Pierangelo Masarati wrote: >>> Should be fixed in HEAD. Please test. p. >> Nope. Synced head, make distclean and re-installed. But still it does >> not start (see log below). > > Should be fixed now (no need to distclean; just make sure dds is re-built > and re-installed!). Please, re-test. Yupp. Works as expected now. Thank you. Ciao, Michael.

1 0

Re: (ITS#5268) dSAOperation attributes should not be replicated
by ghenry＠suretecsystems.com 08 Dec '07

08 Dec '07

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD/RE24/RE23 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > Operational attributes like auditContext and contextCSN that are specific to a > particular DSA should never be replicated. > > It may make sense to add a check in slap_send_search_entry to skip all > dSAOperation attributes at that point. That would catch all instances, but it > would mean they were generated needlessly by whatever code manages the > attribute. > > For now, patching accesslog.c and syncprov.c seems more useful. > Excellent, this solves having to load accesslog on the consumer. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by ando＠sys-net.it 08 Dec '07

08 Dec '07

> Pierangelo Masarati wrote: >> Should be fixed in HEAD. Please test. p. > > Nope. Synced head, make distclean and re-installed. But still it does > not start (see log below). Should be fixed now (no need to distclean; just make sure dds is re-built and re-installed!). Please, re-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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by michael＠stroeder.com 08 Dec '07

08 Dec '07

Pierangelo Masarati wrote: > Should be fixed in HEAD. Please test. p. Nope. Synced head, make distclean and re-installed. But still it does not start (see log below). slapd.conf contains: overlay dds dds-state true dds-max-ttl 86400 dds-min-ttl 1 dds-default-ttl 3600 dds-interval 60 dds-tolerance 0 dds-max-dynamicObjects 100 Ciao, Michael. ----------------------------------------------------------------------- backend_startup_one: starting "cn=accesslog,dc=block-floete,dc=de" bdb_db_open: database "cn=accesslog,dc=block-floete,dc=de": dbenv_open(/home/michael/Bizness/OpenLDAP/ODD_2006/data/accesslog). backend_startup_one: starting "ou=odd2006,dc=block-floete,dc=de" hdb_db_open: database "ou=odd2006,dc=block-floete,dc=de": dbenv_open(/home/michael/Bizness/OpenLDAP/ODD_2006/data/bv). put_filter: "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20071208175929Z))" put_filter: AND put_filter_list "(objectClass=dynamicObject)(entryExpireTimestamp<=20071208175929Z)" put_filter: "(objectClass=dynamicObject)" put_filter: simple put_simple_filter: "objectClass=dynamicObject" put_filter: "(entryExpireTimestamp<=20071208175929Z)" put_filter: simple put_simple_filter: "entryExpireTimestamp<=20071208175929Z" ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: => hdb_search bdb_dn2entry("ou=odd2006,dc=block-floete,dc=de") => hdb_dn2id("ou=odd2006,dc=block-floete,dc=de") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=-1 op=0 p=0 DDS expired objects lookup failed err=0 put_filter: "(objectClass=dynamicObject)" put_filter: simple put_simple_filter: "objectClass=dynamicObject" ber_scanf fmt ({mm}) ber: => hdb_search bdb_dn2entry("ou=odd2006,dc=block-floete,dc=de") => hdb_dn2id("ou=odd2006,dc=block-floete,dc=de") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=-1 op=0 p=0 DDS non-expired objects lookup failed err=32 backend_startup_one: bi_db_open failed! (1) slapd-odd2006 shutdown: initiated ====> bdb_cache_release_all ==> unique_close ====> bdb_cache_release_all slapd-odd2006 destroy: freeing system resources. ==> unique_db_destroy slapd stopped. connections_destroy: nothing to destroy.

1 0

Re: (ITS#5269) few glitches in man pages
by hyc＠symas.com 08 Dec '07

08 Dec '07

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.3.39 > OS: > URL: http://www.zarb.org/~guillomovitch/openldap-2.3.39-man.patch > Submission from: (NULL) (82.224.237.5) > > > Some options are missing in command synopsys, while documented in available > options (-P for ldapwhoami, -H for ldapadd), and others are erroneous (-R > authcid for ldappasswd). Submitted patch fix the issue. Thanks for the patch. -P should be invalid for ldapwhoami since it uses an extended operation, and those are not supported in LDAPv2. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5269) few glitches in man pages
by Guillaume.Rousse＠inria.fr 08 Dec '07

08 Dec '07

Full_Name: Guillaume Rousse Version: 2.3.39 OS: URL: http://www.zarb.org/~guillomovitch/openldap-2.3.39-man.patch Submission from: (NULL) (82.224.237.5) Some options are missing in command synopsys, while documented in available options (-P for ldapwhoami, -H for ldapadd), and others are erroneous (-R authcid for ldappasswd). Submitted patch fix the issue.

1 0

(ITS#5268) dSAOperation attributes should not be replicated
by hyc＠OpenLDAP.org 08 Dec '07

08 Dec '07

Full_Name: Howard Chu Version: HEAD/RE24/RE23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Operational attributes like auditContext and contextCSN that are specific to a particular DSA should never be replicated. It may make sense to add a check in slap_send_search_entry to skip all dSAOperation attributes at that point. That would catch all instances, but it would mean they were generated needlessly by whatever code manages the attribute. For now, patching accesslog.c and syncprov.c seems more useful.

1 0

Re: (ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by ando＠sys-net.it 08 Dec '07

08 Dec '07

Should be fixed in HEAD. 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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by ando＠sys-net.it 08 Dec '07

08 Dec '07

> bdb_dn2entry("ou=odd2006,dc=block-floete,dc=de") > => hdb_dn2id("ou=odd2006,dc=block-floete,dc=de") > <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found > (-30989) > send_ldap_result: conn=-1 op=0 p=0 > DDS expired objects lookup failed err=32 Makes sense to skip searching for expired entries in a non existing database... 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: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5267) slapo-dds prevents slapd from starting in case of an empty DB
by michael＠stroeder.com 08 Dec '07

08 Dec '07

Full_Name: Michael Ströder Version: HEAD OS: OpenSUSE Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.3.18) Situation: 1. slapo-dds is defined for database ou=odd2006,dc=block-floete,dc=de in slapd.conf 2. entry ou=odd2006,dc=block-floete,dc=de does not yet exist => slapd does not start (see log below). For the ease of initial setup I'd prefer that slapd would start. bdb_dn2entry("ou=odd2006,dc=block-floete,dc=de") => hdb_dn2id("ou=odd2006,dc=block-floete,dc=de") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=-1 op=0 p=0 DDS expired objects lookup failed err=32 backend_startup_one: bi_db_open failed! (1) slapd-odd2006 shutdown: initiated

1 0

Re: (ITS#5264) invalid printf of NULL
by hyc＠symas.com 07 Dec '07

07 Dec '07

Aaron Richton wrote: > "./run test044" is sufficient to reproduce 100% of the time. Maybe the > behavior's changed in S10 (or maybe gcc does some wrapping, I don't know) > but printf("%s", NULL) has been an instant SEGV in Sol9 as long as I can > remember... >>> (dbx) print assertDN->bv_val >>> assertDN->bv_val = (nil) >>> >>> don't do that... As I suspected, there's more wrong here than a bad printf argument. The assertDN should never be NULL. -- -- Howard Chu Chief Architect, 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#5264) invalid printf of NULL
by hyc＠symas.com 07 Dec '07

07 Dec '07

Aaron Richton wrote: > "./run test044" is sufficient to reproduce 100% of the time. Maybe the > behavior's changed in S10 (or maybe gcc does some wrapping, I don't know) > but printf("%s", NULL) has been an instant SEGV in Sol9 as long as I can > remember... Yes, understood. That characteristic of Solaris hasn't changed. But test044 in HEAD exercises code that hasn't been included in RE24, and I was focusing on RE24. -- -- Howard Chu Chief Architect, 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#5264) invalid printf of NULL
by richton＠nbcs.rutgers.edu 07 Dec '07

07 Dec '07

"./run test044" is sufficient to reproduce 100% of the time. Maybe the behavior's changed in S10 (or maybe gcc does some wrapping, I don't know) but printf("%s", NULL) has been an instant SEGV in Sol9 as long as I can remember... On Fri, 7 Dec 2007, Howard Chu wrote: > richton(a)nbcs.rutgers.edu wrote: >> Full_Name: Aaron Richton >> Version: HEAD >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.6.31.137) > > In a separate email you mentioned that you ran into this problem in > test044-dynlist. That test passes for me on Solaris 10/sparcv9. How exactly > did you get this to occur? > >> [5] slap_sasl_match(opx = 0x100a32c10, rule = 0x100a363e0, assertDN = >> 0x7fffffff7927c6c0, authc = 0x7fffffff7927c6c0), line 1668 in "saslauthz.c" >> >> 1660 struct berval base = BER_BVNULL; >> 1661 >> 1662 sm.dn = assertDN; >> 1663 sm.match = 0; >> 1664 cb.sc_private = &sm; >> 1665 >> 1666 Debug( LDAP_DEBUG_TRACE, >> 1667 "===>slap_sasl_match: comparing DN %s to rule %s\n", >> 1668 assertDN->bv_val, rule->bv_val, 0 ); >> 1669 >> 1670 /* NOTE: don't normalize rule if authz syntax is enabled */ >> >> (dbx) print assertDN->bv_val >> assertDN->bv_val = (nil) >> >> don't do that... >> >> >> . >> > > > -- > -- Howard Chu > Chief Architect, 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#5109) ldap_int_global_options not initialized
by lighthousej＠gmail.com 07 Dec '07

07 Dec '07

------=_Part_13800_24934559.1197042335995 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think this issue is related to Oracle libraries. I got pretty much the same backtrace using openldap 2.3.32 with oracle 10g libs with my program. The code seems to want to copy an array of strings which contain attributes from the global variable. The problem is that the pointer to the attribute strings array isn't pointing to the address holding the first string pointer, it's actually pointing to the first character of a string. The code thinks the first four bytes (which are really the first four characters) is a memory address, tries to strlen that address and faults because it's out of bounds. I moved the oracle libs out of the way, soft symlinked the oracle filenames to zlib and the same exact binary worked fine. I'm trying out 2.4.6 right now but I wanted to relay this is potentially a bug related to including Oracle. ------=_Part_13800_24934559.1197042335995 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think this issue is related to Oracle libraries. I got pretty much the same backtrace using openldap 2.3.32 with oracle 10g libs with my program. The code seems to want to copy an array of strings which contain attributes from the global variable.  The problem is that the pointer to the attribute strings array isn't pointing to the address holding the first string pointer, it's actually pointing to the first character of a string.  The code thinks the first four bytes (which are really the first four characters) is a memory address, tries to strlen that address and faults because it's out of bounds. I moved the oracle libs out of the way, soft symlinked the oracle filenames to zlib and the same exact binary worked fine. I'm trying out 2.4.6 right now but I wanted to relay this is potentially a bug related to including Oracle. ------=_Part_13800_24934559.1197042335995--

1 0

Re: (ITS#5264) invalid printf of NULL
by hyc＠symas.com 07 Dec '07

07 Dec '07

hyc(a)symas.com wrote: > richton(a)nbcs.rutgers.edu wrote: >> Full_Name: Aaron Richton >> Version: HEAD >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.6.31.137) > > In a separate email you mentioned that you ran into this problem in > test044-dynlist. That test passes for me on Solaris 10/sparcv9. How exactly > did you get this to occur? Never mind, I'm testing RE24, not HEAD. This part of dynlist isn't present in RE24. > >> [5] slap_sasl_match(opx = 0x100a32c10, rule = 0x100a363e0, assertDN = >> 0x7fffffff7927c6c0, authc = 0x7fffffff7927c6c0), line 1668 in "saslauthz.c" >> >> 1660 struct berval base = BER_BVNULL; >> 1661 >> 1662 sm.dn = assertDN; >> 1663 sm.match = 0; >> 1664 cb.sc_private = &sm; >> 1665 >> 1666 Debug( LDAP_DEBUG_TRACE, >> 1667 "===>slap_sasl_match: comparing DN %s to rule %s\n", >> 1668 assertDN->bv_val, rule->bv_val, 0 ); >> 1669 >> 1670 /* NOTE: don't normalize rule if authz syntax is enabled */ >> >> (dbx) print assertDN->bv_val >> assertDN->bv_val = (nil) >> >> don't do that... >> >> >> . >> > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs