- openldap-bugs - openldap.org

Re: (ITS#6749) Shut up "configure monitor database to enable"
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

> Full_Name: Hallvard B Furuseth > Version: 2.4.23 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Please don't give the "configure monitor database to enable" message > by default. > > Either just remove it, or better, stop cn=config from adding a default > olcMonitoring: TRUE attribute to olcDatabase objects. (The flag value > can still default to True if the attribute is absent.) Then you can > give the message if the _admin_ has explicitly asked for monitoring, > instead of if slapd has asked for it. I disagree; it is not cn=config that defaults database monitoring to TRUE; actually, it's back-bdb/back-hdb that sets its own monitoring to TRUE as soon as back-monitor support is compiled and the specific backend monitoring is successfully initilized. Maybe this warning can be demoted to LDAP_DEBUG_CONFIG instead of LDAP_DEBUG_ANY. I understand that one could presume that the lack of database monitor in the configuration indicates that monitoring is not desired; this warning, however, tries to address a typical configuration error, when admins just forget to configure it. p.

1 0

Re: (ITS#6700) memberOf overlay does not handle MODRDN correctly
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

> raphael.ouazana(a)linagora.com wrote: > >> When using memberOf overlay, a MODRDN request on a member does not >> update >> correctly the matching group, even if the memberof-refint option is set >> to >> true. >> >> In my little understanding, memberof_value_modify calls >> op->o_bd->be_modify >> which calls back the overlay code, and finally never reach the backend. > > Guess what, modrdn is the only operation test052 does not check :( > WOrking at it. Thanks, p. Fixed in HEAD; please test and report. Please note that test052 and the corresponding expected output data have been modified to check modrdn. p.

1 0

(ITS#6765) Server-side support of "Verify Credentials" extop
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando Added module in contrib/slapd-modules/vc/; no spec yet, simply mimicking the companion of what is currently implemented in libraries/libldap/vc.c. The current code should support SASL; untested yet, since the client does not implement SASL support yet. p.

1 0

(ITS#6764) ber_flatten() should return -1 on unmatched "{" "}"
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando also per <draft-ietf-ldapext-ldap-c-api>. p.

1 0

Re: (ITS#6758) Cleaning up SlapReply usage
by hyc＠symas.com 31 Dec '10

31 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Mostly done with the easily spotted cases. Hopefully HEAD's code > stayed valid through my commits. Need to think some more for the > rest. The decisions with greater chance of breaking things > remain, like ITS#6763. > > Other issues: > > * hyc, please have a look at slapd/bconfig.c 1.419. If I have > gotten things wrong, that one summarizes my mistakes nicely:-) I think you're over-paranoid. config_build_entry() is only called by internal plumbing and the SlapReply here never gets sent to send_ldap_result(). It's only passed in because be_add() expects one; the contents are mostly irrelevant. (Aside from rs_err) -- -- 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#6758) Cleaning up SlapReply usage
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

Mostly done with the easily spotted cases. Hopefully HEAD's code stayed valid through my commits. Need to think some more for the rest. The decisions with greater chance of breaking things remain, like ITS#6763. Other issues: * hyc, please have a look at slapd/bconfig.c 1.419. If I have gotten things wrong, that one summarizes my mistakes nicely:-) * If slap_send_ldap_result() or send_ldap_disconnect() see an entry with REP_ENTRY_MUST<RELEASE/BEFREED> and REP_SEARCH/SEARCHREF, should release/free the entry? That helps code which sends error without freeing sr_entry. It breaks if the entry comes from another Operation, or if the caller reuses a Search SlapReply for a non-Search and trusts rs->sr_un.sru_search to stay untouched. * Is the code getting clean enough that slap_send_search_entry's cleanup code can flush the entry independently of whether op->o_tag == LDAP_REQ_SEARCH? * slapi/slapi_pblock.c 1.81: /* TODO: Should REP_ENTRY_MODIFIABLE be set? */ I've no idea, and I've more pressing things to look at... Notes on the updates: * "Reset some SlapReply flags & data" commits vs "avoid SlapReply reuse" commits: The combination might be redundant/overcautious, but tries to catch problems from remaining unclean code from both ends. * result.c, freeing as well as releasing entries as soon as possible: More readable, and since the entry isn't needed: The sooner we get rid of it, the less chance for an entry leak. * commits "Use rs_*() to manage SlapReply entries." Switching to rs_flush_entry(): - result.c:slap_send_search_entry(), overlays/pcache.c, overlays/translucent.c, slapi/slapi_pblock.c: These did not clear the MODIFIABLE flag along with MUSTBEFREED. Switching to use rs_ensure_entry_modifiable(): - syncprov_operational(), overlay collect: noop change (except operational should not update the entry) - overlay valsort: It needlessly required REP_ENTRY_MUSTBEFREED as well as MODIFIABLE. But the entry can also be MODIFIABLE and e.g. on the stack. - contrib overlays cloak, usn: Had entry leaks. -- Hallvard

1 0

(ITS#6763) slapd does not clear sr_entry/ctrls on sizelimit/busy
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slap_send_search_entry() does not always free/release the entry and call slap_cleanup_play() on error. slap_send_search_reference() calls slap_cleanup_play(), but does not always free/release the entry. I expect both functions always should do both, but don't know enough myself to be sure. Resolution needed for ITS#6758 (SlapReply) - who should be responsible for clearing out the entry?

1 0

(ITS#6762) cloak overlay only works on first search entry
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard The cloak overlay only works on the first entry returned from a search. Then it removes the callback, and the remaining attributes are uncloaked. I checked this by removing the call to slap_freeself_cb() and the setting of sc_cleanup, then it worked. And probably got a leak somewhere, but I don't have time to find the right fix now.

1 0

(ITS#6761) contrib usn overlay broken
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard The usn overlay: - Has init function usn_init instead of usn_initialize. - Won't start, the attributes need a SYNTAX slapd knows and USAGE directoryOperation after NO-USER-MODIFICATION. - Modifies sr->sr_entry in usn_operational() instead of putting the attribute in rs->sr_operational_attrs. See back-bdb/operational.c for an example. Note, backend.c says /* NOTE: backend_operational() is also called * when returning results, so it's supposed * to do no harm to entries */ which presumably means something more than just having to dup the entry and set MUSTBEFREED, since otherwise that comment applies to much more than just backend_operational(). In fact, usn_operational() has some misindented code if ( !a ) { for ( ap = &rs->sr_operational_attrs; *ap; ap=&(*ap)->a_next ); a = attr_alloc( ad_usnChanged ); *ap = a; } which looks like it does something closer to that. - When I tried to slapadd some entires (using Octet String syntax) only the first entry got an USN. Oh well, this wasn't what I was supposed to be doing today. I'm just patching the overlay blindly for some other things (ITS#6758).

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by B.Candler＠pobox.com 31 Dec '10

31 Dec '10

I get similar behaviour using Cyrus SASL's sample-client and sample-server: ... Negotiation complete Username: student(a)REALM3.WS.NSRC.ORG Realm: (NULL) SSF: 56 ... Now, in sample-server.c, the displayed realm comes from result = sasl_getprop(conn, SASL_DEFUSERREALM, (const void **)&data); which suggests this is intended to be the default realm, not the realm of the user connecting. And clearly the username does include the Kerberos realm. But I'm having difficulty finding the corresponding OpenLDAP code to extract the realm. Is it making use of session callbacks, and expects Cyrus to call slap_sasl_canonicalize (SASL_CB_CANON_USER) with the user_realm parameter? Regards, Brian.

1 0

(ITS#6760) rwm broken entry handling
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard rwm_entry_get_rw() returns failure with an entry in *ep if rwm_send_entry() fails. rwm_send_entry() does not honor REP_ENTRY_MUSTBEFREED. And its ITS#6423 bugcatch can be done before entry_dup(). Fixing - I think - but my fix could use some extra eyes. In particuar, am I right about using be_entry_release_r() or should it have used overlay_entry_release_ov() which rs_replace_entry() uses? Or should rwm_send_entry() use different release methods depending on whether it is called by rwm.on_response or rwm.on_bi.bi_entry_get_rw?

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by hyc＠symas.com 30 Dec '10

30 Dec '10

b.candler(a)pobox.com wrote: > Full_Name: Brian Candler > Version: 2.4.21 > OS: Ubuntu 10.04.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.114.104.19) > > > DOcumentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI gives two > example authorization DNs built from SASL/GSSAPI: > > "a user with the Kerberos principal kurt(a)EXAMPLE.COM would have the associated > DN: > uid=kurt,cn=example.com,cn=gssapi,cn=auth > and the principal ursula/admin(a)FOREIGN.REALM would have the associated DN: > uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth" > > Experimentation shows that the actual behaviour is different. > > You could treat this either as a behaviour error or a documentation error - if > the latter, the olcSaslRealm is pretty useless, because if set it appears in all > auth DNs (for both local and foreign realms) Could be a bug, but we're using the parameters as documented by Cyrus. I suggest you file this bug report with them instead. -- -- 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#6755) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by hyc＠symas.com 30 Dec '10

30 Dec '10

jgilmour(a)techsmog.com wrote: > Full_Name: Josh Gilmour > Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14) > OS: CentOS release 5.4 32bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (38.112.23.58) > > > I get a segfault when using the following command and applying a filter file. If > we remove the -f, the command runs properly. It doesn't seem to be a major > security issue (or one at all, I'm not sure), but it does seem to be a bug I > believe... OpenLDAP 2.3 is no longer supported. If you can reproduce this bug in a current release please followup with the relevant stack trace, otherwise this ITS will be closed. Currently I see no such symptom in 2.4.x. -- -- 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#6678
by hyc＠symas.com 30 Dec '10

30 Dec '10

The best thing to do in a hang situation is to attach to the server with gdb and get a stack trace of all of the active threads. http://www.openldap.org/faq/data/cache/59.html -- -- 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#6670) memberof overlay problem
by hyc＠symas.com 30 Dec '10

30 Dec '10

henjes(a)informatik.uni-wuerzburg.de wrote: > Full_Name: Robert Henjes > Version: 2.4.23-4 > OS: Debian Squeeze > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.187.12.89) > > > Hi, > > while using memberof overlay I recognized the following problem in conjunction > with groupOfNames. If you try to add an empty group of names you have to set at > least one member attribute, since it is mandatory. One could have the idea to > point to the group dn itself. If having the memberof overlay active this leads > to a loop while executing an ldapadd. I assume this happens while the memberof > overlay is triggered. Tried to analyze the slapd debug output, but it stops, > after the addition is completed. > > Example LDIF file: > dn: cn=stupid,ou=groups,dc=domain > objectClass: top > objectClass: groupOfNames > cn: stupid > member: cn=stupid,ou=groups,dc=domain > > The slapd server seems proceed working, except the add process and the subtree > where the LDIF is gets added. You can not stop the slapd server in a normal way, > you just have to do a "kill -9". After that the LDIF file seems to be added, but > I assume, that the memberof overlay representation is inconsistent. > > The memberof overlay should be aware of such situations, even if building loops > in dn references is in general not a good idea. The memberof code in HEAD has been patched to ignore these cases. Possibly we can add additional code to insert the member/memberOf value as appropriate, but I haven't done so in 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/

1 0

(ITS#6759) assert;Debug -> Debug;assert
by h.b.furuseth＠usit.uio.no 30 Dec '10

30 Dec '10

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard OpenLDAP sometimes does assert() before Debug(). assert is more convenient after Debug, so more info is readily available for debugging. Except when the assert catches that Debug would crash. I'll update some cases, including for soon-to-be-committed asserts.

1 0

(ITS#6758) Cleaning up SlapReply usage
by h.b.furuseth＠usit.uio.no 30 Dec '10

30 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: Linux x86_64 URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Slapd and its modules put varous info in SlapReply and send it. They do not always clean it up afterwards, or not correctly. Then they sometimes reuse the SlapReply without reinitializing, even though most of its fields are invalid at that point. (In practice they are usually mostly zeroed by then, so slapd works anyway.) This is a dup of the misnamed ITS#5340, so the CHANGES file can refer to an ITS with a better name for all the upcoming commits. Also I'll go about it a bit backwards than discussed there: First reset some flags and avoid reusing SlapReply, then get more aggressive about obeying the flag settings that remain.

1 0

(ITS#6757) SASL canonicalize doesn't work as documented
by b.candler＠pobox.com 30 Dec '10

30 Dec '10

Full_Name: Brian Candler Version: 2.4.21 OS: Ubuntu 10.04.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.114.104.19) DOcumentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI gives two example authorization DNs built from SASL/GSSAPI: "a user with the Kerberos principal kurt(a)EXAMPLE.COM would have the associated DN: uid=kurt,cn=example.com,cn=gssapi,cn=auth and the principal ursula/admin(a)FOREIGN.REALM would have the associated DN: uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth" Experimentation shows that the actual behaviour is different. (1) If the realm of the client is the same as the default_realm on the server, then the auth DN is uid=kurt,cn=<olcSaslRealm>,cn=gssapi,cn=auth (2) If the realm of the client is different to the default_realm on the server, then the auth DN is uid=ursula/admin(a)foreign.realm,cn=<olcSaslRealm>,cn=gssapi,cn=auth (If olcSaslRealm is unset in the config then cn=<olcSaslRealm> is omitted entirely) Some real examples are shown below. I reproduced this in a cross-realm auth setup with two MIT Kerberos 1.8.1 KDCs. The realms are WS.NSRC.ORG and REALM3.WS.NSRC.ORG. The server is host noc.ws.nsrc.org and is in realm WS.NSRC.ORG. It has a keytab for ldap/noc.ws.nsrc.org(a)WS.NSRC.ORG, and has olcSaslRealm: EXAMPLE.COM (which is just a junk realm, but it makes it clear that this isn't used for authentication) When a client presents a ticket for inst(a)WS.NSRC.ORG: do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=<continuing> datalen=32 SASL Canonicalize [conn=1000]: authcid="inst" slap_sasl_getdn: conn 1000 id=inst [len=4] => ldap_dn2bv(16) <= ldap_dn2bv(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth >>> dnNormalize: <uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth> => ldap_bv2dn(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0) <= ldap_bv2dn(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=inst,cn=example.com,cn=gssapi,cn=auth)=0 <<< dnNormalize: <uid=inst,cn=example.com,cn=gssapi,cn=auth> ==>slap_sasl2dn: converting SASL name uid=inst,cn=example.com,cn=gssapi,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=1000]: slapAuthcDN="uid=inst,cn=example.com,cn=gssapi,cn=auth" SASL proxy authorize [conn=1000]: authcid="inst(a)EXAMPLE.COM" authzid="inst(a)EXAMPLE.COM" SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/GSSAPI bind: dn="uid=inst,cn=example.com,cn=gssapi,cn=auth" sasl_ssf=56 When a client presents a ticket for student(a)REALM3.WS.NSRC.ORG: do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=<continuing> datalen=32 SASL Canonicalize [conn=1000]: authcid="student(a)REALM3.WS.NSRC.ORG" slap_sasl_getdn: conn 1000 id=student(a)REALM3.WS.NSRC.ORG [len=26] => ldap_dn2bv(16) <= ldap_dn2bv(uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth >>> dnNormalize: <uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth> => ldap_bv2dn(uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0) <= ldap_bv2dn(uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth)=0 <<< dnNormalize: <uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth> ==>slap_sasl2dn: converting SASL name uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=1000]: slapAuthcDN="uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth" SASL proxy authorize [conn=1000]: authcid="student(a)REALM3.WS.NSRC.ORG" authzid="student(a)REALM3.WS.NSRC.ORG" SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/GSSAPI bind: dn="uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth" sasl_ssf=56 You can see that the authcid from libsasl omits the realm when it's the same as the server's, and includes the realm when it's different. However openldap does not split out into "uid=ursula/admin,cn=foreign.realm" as the documentation says. You could treat this either as a behaviour error or a documentation error - if the latter, the olcSaslRealm is pretty useless, because if set it appears in all auth DNs (for both local and foreign realms)

1 0

Re: (ITS#6756) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by jgilmour＠brightcove.com 30 Dec '10

30 Dec '10

--90e6ba211d7d01d52c0498a713c3 Content-Type: text/plain; charset=ISO-8859-1 oops, sorry, this is a duplicate On Thu, Dec 30, 2010 at 4:06 PM, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6756. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6756) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6756) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6756 > > Please remember to retain your issue tracking number (ITS#6756) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > -- Josh Gilmour | Windows Systems & Network Administrator Brightcove, Inc. www.brightcove.com One Cambridge Center, 12th Floor, Cambridge, MA 02142 P: 617.395.5843 F: 617.395.8352 ++++++++++ Brightcove PLAY 2011 Global Customer Conference May 23-25, Boston Seaport Hotel & World Trade Center Registration Now Open: http://brightcove.com/play2011 ++++++++++ --90e6ba211d7d01d52c0498a713c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable oops, sorry, this is a duplicate <div class=3D"gmail_quote">On Thu, = Dec 30, 2010 at 4:06 PM, <<a href=3D"mailto:openldap-= its(a)openldap.org">openldap-its(a)openldap.org</a>> wrote: <block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex;"> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. =A0Your report has been assigned the tracking number ITS#6756. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. =A0They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. =A0Note that any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#6756) in the subject will automatically be attached to the issue report. =A0 =A0 =A0 =A0mailto:<a href=3D"mailto:openldap-its@openldap.org">openlda= p-its(a)openldap.org</a>?subject=3D(ITS#6756) You may follow the progress of this report by loading the following URL in a web browser: =A0 =A0<a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D6756" tar= get=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D6756</a> Please remember to retain your issue tracking number (ITS#6756) on any further messages you send to us regarding this report. =A0If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =A0 =A0 =A0 =A0<a href=3D"http://www.OpenLDAP.org/support/" target=3D"_bla= nk">http://www.OpenLDAP.org/support/</a> -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. </blockquote></div> -- Josh Gilmour | Windows = Systems & Network Administrator Brightcove, Inc. <a href=3D"http= ://www.brightcove.com">www.brightcove.com</a> One Cambridge Center, 12th= Floor, Cambridge, MA 02142 P: 617.395.5843 F: 617.395.8352 ++++++++++ Brightcove PLAY 2= 011 Global Customer Conference May 23-25, Boston Seaport Hotel &= World Trade Center Registration Now Open: <a href=3D"http://brightc= ove.com/play2011">http://brightcove.com/play2011</a> ++++++++++ --90e6ba211d7d01d52c0498a713c3--

1 0

(ITS#6756) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by jgilmour＠techsmog.com 30 Dec '10

30 Dec '10

Full_Name: Josh Gilmour Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14) OS: CentOS release 5.4 32bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.112.23.58) I get a segfault when using the following command and applying a filter file. If we remove the -f, the command runs properly. It doesn't seem to be a major security issue (or one at all, I'm not sure), but it does seem to be a bug I believe... the file i'm using for the -f parameter, 'testing', just has the letter 'a' in it. Here is the process output from gdb: [jgilmour@xijgilmour ~]$ gdb ldapsearch GNU gdb Fedora (6.8-37.el5) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (no debugging symbols found) (gdb) r -x -LLL -h xxx.local -D "xxx(a)xxx.local" -E pr=1/noprompt -w password -b "OU=xxx,dc=xxx,dc=local" -S sAMAccountName -f testing Starting program: /usr/bin/ldapsearch -x -LLL -h xxx.local -D "xxx(a)xxx.local" -E pr=1/noprompt -w password -b "OU=xxx,dc=xxx,dc=local" -S sAMAccountName -f testing (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) dn: OU=xxx,DC=xxx,DC=LOCAL objectClass: top objectClass: organizationalUnit ou: xxx distinguishedName: OU=xxx,DC=xxx,DC=LOCAL instanceType: 4 whenCreated: 20050103174000.0Z whenChanged: 20081117191042.0Z uSNCreated: 12371 uSNChanged: 6388825 name: xxx objectGUID:: qjRiugCNd0eXyrXkHlETpA== objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=xxx,D C=LOCAL dSCorePropagationData: 20080818221029.0Z dSCorePropagationData: 20080628202026.0Z dSCorePropagationData: 20070611215308.0Z dSCorePropagationData: 20070611213209.0Z dSCorePropagationData: 16010714223649.0Z *** glibc detected *** /usr/bin/ldapsearch: double free or corruption (!prev): 0x086a35f8 *** Program received signal SIGSEGV, Segmentation fault. 0x00c67a3f in _int_malloc () from /lib/i686/nosegneg/libc.so.6 (gdb) i r eax 0x169 361 ecx 0xd43170 13906288 edx 0x86a35f0 141178352 ebx 0xd41ff4 13901812 esp 0xbf9a7078 0xbf9a7078 ebp 0xbf9a713c 0xbf9a713c esi 0x168 360 edi 0xb7fdb000 -1208111104 eip 0xc67a3f 0xc67a3f <_int_malloc+703> eflags 0x210283 [ CF SF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) bt #0 0x00c67a3f in _int_malloc () from /lib/i686/nosegneg/libc.so.6 #1 0x00c69a1e in malloc () from /lib/i686/nosegneg/libc.so.6 #2 0x00235998 in _dl_map_object () from /lib/ld-linux.so.2 #3 0x0023ead1 in dl_open_worker () from /lib/ld-linux.so.2 #4 0x0023ae66 in _dl_catch_error () from /lib/ld-linux.so.2 #5 0x0023e4b2 in _dl_open () from /lib/ld-linux.so.2 #6 0x00d08072 in do_dlopen () from /lib/i686/nosegneg/libc.so.6 #7 0x0023ae66 in _dl_catch_error () from /lib/ld-linux.so.2 #8 0x00d08225 in __libc_dlopen_mode () from /lib/i686/nosegneg/libc.so.6 #9 0x00ce44d9 in init () from /lib/i686/nosegneg/libc.so.6 #10 0x00ce4673 in backtrace () from /lib/i686/nosegneg/libc.so.6 #11 0x00c5ee51 in __libc_message () from /lib/i686/nosegneg/libc.so.6 #12 0x00c671d5 in _int_free () from /lib/i686/nosegneg/libc.so.6 #13 0x00c67619 in free () from /lib/i686/nosegneg/libc.so.6 #14 0x00c55756 in fclose@@GLIBC_2.1 () from /lib/i686/nosegneg/libc.so.6 #15 0x0804ca88 in ?? () #16 0x00c12e9c in __libc_start_main () from /lib/i686/nosegneg/libc.so.6 #17 0x0804a3f1 in ?? () (gdb) q The program is running. Exit anyway? (y or n) y [jgilmour@xijgilmour ~]$ uname -a Linux xijgilmour.xxx.local 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 20 08:53:10 EST 2010 i686 i686 i386 GNU/Linux

1 0

(ITS#6755) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by jgilmour＠techsmog.com 30 Dec '10

30 Dec '10

Full_Name: Josh Gilmour Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14) OS: CentOS release 5.4 32bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.112.23.58) I get a segfault when using the following command and applying a filter file. If we remove the -f, the command runs properly. It doesn't seem to be a major security issue (or one at all, I'm not sure), but it does seem to be a bug I believe... the file i'm using for the -f parameter, 'testing', just has the letter 'a' in it. Here is the process output from gdb: [jgilmour@xijgilmour ~]$ gdb ldapsearch GNU gdb Fedora (6.8-37.el5) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (no debugging symbols found) (gdb) r -x -LLL -h xxx.local -D "xxx(a)xxx.local" -E pr=1/noprompt -w password -b "OU=xxx,dc=xxx,dc=local" -S sAMAccountName -f testing Starting program: /usr/bin/ldapsearch -x -LLL -h xxx.local -D "xxx(a)xxx.local" -E pr=1/noprompt -w password -b "OU=xxx,dc=xxx,dc=local" -S sAMAccountName -f testing (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) dn: OU=xxx,DC=xxx,DC=LOCAL objectClass: top objectClass: organizationalUnit ou: xxx distinguishedName: OU=xxx,DC=xxx,DC=LOCAL instanceType: 4 whenCreated: 20050103174000.0Z whenChanged: 20081117191042.0Z uSNCreated: 12371 uSNChanged: 6388825 name: xxx objectGUID:: qjRiugCNd0eXyrXkHlETpA== objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=xxx,D C=LOCAL dSCorePropagationData: 20080818221029.0Z dSCorePropagationData: 20080628202026.0Z dSCorePropagationData: 20070611215308.0Z dSCorePropagationData: 20070611213209.0Z dSCorePropagationData: 16010714223649.0Z *** glibc detected *** /usr/bin/ldapsearch: double free or corruption (!prev): 0x086a35f8 *** Program received signal SIGSEGV, Segmentation fault. 0x00c67a3f in _int_malloc () from /lib/i686/nosegneg/libc.so.6 (gdb) i r eax 0x169 361 ecx 0xd43170 13906288 edx 0x86a35f0 141178352 ebx 0xd41ff4 13901812 esp 0xbf9a7078 0xbf9a7078 ebp 0xbf9a713c 0xbf9a713c esi 0x168 360 edi 0xb7fdb000 -1208111104 eip 0xc67a3f 0xc67a3f <_int_malloc+703> eflags 0x210283 [ CF SF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) bt #0 0x00c67a3f in _int_malloc () from /lib/i686/nosegneg/libc.so.6 #1 0x00c69a1e in malloc () from /lib/i686/nosegneg/libc.so.6 #2 0x00235998 in _dl_map_object () from /lib/ld-linux.so.2 #3 0x0023ead1 in dl_open_worker () from /lib/ld-linux.so.2 #4 0x0023ae66 in _dl_catch_error () from /lib/ld-linux.so.2 #5 0x0023e4b2 in _dl_open () from /lib/ld-linux.so.2 #6 0x00d08072 in do_dlopen () from /lib/i686/nosegneg/libc.so.6 #7 0x0023ae66 in _dl_catch_error () from /lib/ld-linux.so.2 #8 0x00d08225 in __libc_dlopen_mode () from /lib/i686/nosegneg/libc.so.6 #9 0x00ce44d9 in init () from /lib/i686/nosegneg/libc.so.6 #10 0x00ce4673 in backtrace () from /lib/i686/nosegneg/libc.so.6 #11 0x00c5ee51 in __libc_message () from /lib/i686/nosegneg/libc.so.6 #12 0x00c671d5 in _int_free () from /lib/i686/nosegneg/libc.so.6 #13 0x00c67619 in free () from /lib/i686/nosegneg/libc.so.6 #14 0x00c55756 in fclose@@GLIBC_2.1 () from /lib/i686/nosegneg/libc.so.6 #15 0x0804ca88 in ?? () #16 0x00c12e9c in __libc_start_main () from /lib/i686/nosegneg/libc.so.6 #17 0x0804a3f1 in ?? () (gdb) q The program is running. Exit anyway? (y or n) y [jgilmour@xijgilmour ~]$ uname -a Linux xijgilmour.xxx.local 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 20 08:53:10 EST 2010 i686 i686 i386 GNU/Linux

1 0

(ITS#6754) slapd ignores extra command-line arguments
by rein＠OpenLDAP.org 30 Dec '10

30 Dec '10

Full_Name: Rein Tollevik Version: CVS head OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:129a:ddff:fe4b:9c78) Submitted by: rein slapd silently ignores extra command-line arguments not recognized as options. A simple fix is coming. -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6741)
by hyc＠symas.com 30 Dec '10

30 Dec '10

jgcardoso(a)seguridata.com wrote: > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01CBA84D.397A800E > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > I submitted a patch for tls2.c in order to handle DER BitString values. LBER_BITSTRING is already defined in lber.h so there's no need to define LBER_TAG_BITSTRING in your patch. I will clean up some of this and then commit it. -- -- 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#6741)
by jgcardoso＠seguridata.com 30 Dec '10

30 Dec '10

This is a multi-part message in MIME format. ------_=_NextPart_001_01CBA84D.397A800E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I submitted a patch for tls2.c in order to handle DER BitString values. =20 This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by SeguriData Privada, S.A. de CV. SeguriData Privada S.A de C. V. has not assigned rights and/or interest in this work to any party. I, Juan Gonzalez Cardoso am authorized by SeguriData Privada, S. A. de C. V., my employer, to release this work under the following terms: =20 The attached modifications to OpenLDAP Software are subject to the following notice: =20 Copyright SeguriData Privada, S. A. de C. V. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. =20 Full_Name: Juan Gonzalez Cardoso Version: 2.4.23 OS: Red Hat 5.5 EL URL: ftp://ftp.openldap.org/incoming/juan-gonzalez-101230.patch =20 =20 =20 =20 ------_=_NextPart_001_01CBA84D.397A800E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 = (filtered medium)"><style></style></head><body lang=3DES-MX link=3Dblue = vlink=3Dpurple><div class=3DWordSection1>I submitted a patch for tls2.c in order to handle DER = BitString values.<o:p></o:p><o:p> </o:p> This patch file is derived from OpenLDAP Software. All of = the modifications to OpenLDAP Software represented in the following = patch(es) were developed by SeguriData Privada, S.A. de = CV.<o:p></o:p>SeguriData Privada S.A de C. V. has not assigned rights = and/or interest in this work to any party.<o:p></o:p>I, Juan Gonzalez Cardoso am = authorized by SeguriData Privada, S. A. de C. V., my employer, to = release this work under the following terms:<o:p></o:p><o:p> </o:p>The attached modifications to = OpenLDAP Software are subject to the following = notice:<o:p></o:p><o:p> </o:p>Copyright = SeguriData Privada, S. A. de C. V.<o:p></o:p>Redistribution and use in source = and binary forms, with or without modification, are permitted only as = authorized by the OpenLDAP Public License.<o:p></o:p><o:p> </o:p>Full_Name: Juan Gonzalez = Cardoso<o:p></o:p>Version: 2.4.23<o:p></o:p>OS: Red Hat 5.5 = EL<o:p></o:p>URL: <a = href=3D"ftp://ftp.openldap.org/incoming/juan-gonzalez-101230.patch">ftp:/= /ftp.openldap.org/incoming/juan-gonzalez-101230.patch</a><o:p></o:p></spa= n><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p></div></body></html> ------_=_NextPart_001_01CBA84D.397A800E--

1 0

Re: (ITS#6684)
by hyc＠symas.com 30 Dec '10

30 Dec '10

norbert(a)pueschel.net wrote: > Updated TAR-file with (hopefully) sufficient copyright notice... > > http://www.pueschel.net/openldap/norbert-pueschel-autogroup-27102010.tar Your code does a string compare againset "memberOf" to detect those filter references. 1) it should simply be comparing the AttributeDescription pointers 2) since the "memberof" attribute is actually configurable in the memberof overlay, there's no guarantee that this is the correct attribute to be looking for. It should also be configurable in your patch. You're using strcasecmp, but your inputs are already normalized values. You should just use ber_bvcmp. Replying to the original: > 1) Using non-DN-valued URIs for autogroup does not work correctly, even > with the latest version from HEAD. Especially changing group member is > not tracked. I don't see why this should ever work or be supported. LDAP groups list DNs. > 2) Using the memberOf-overlay for constructing autogroups does not work I don't see any reason why this should work. The memberof overlay is not used to construct groups, it is only used to report on group memberships that have already been defined. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs