- openldap-bugs - openldap.org

Re: (ITS#8257) test061-syncreplication-initiation seg faults
by hyc＠symas.com 29 Sep '15

29 Sep '15

michael(a)stroeder.com wrote: > Full_Name: > Version: openSUSE Linux > OS: RE24 branch > URL: > Submission from: (NULL) (84.178.28.66) > > > The current re24 branch seg faults: Thanks, this seems to be a problem with the ITS#8221 patch. Looking into it. > >>>>>> Starting test061-syncreplication-initiation for mdb... > Running defines.sh > Initializing server configurations > Starting provider slapd on ldap://localhost:9011/ > Starting forward1 slapd on ldap://localhost:9013/ > Starting consumer slapd on ldap://localhost:9012/ > Adding schema on ldap://localhost:9011/ > Adding backend module on ldap://localhost:9011/... > Adding schema on ldap://localhost:9012/ > Adding backend module on ldap://localhost:9012/... > Adding schema on ldap://localhost:9013/ > Adding backend module on ldap://localhost:9013/... > Adding database configuration on ldap://localhost:9011/ > Populating provider on ldap://localhost:9011/ > Adding database configuration on ldap://localhost:9013/ > Adding database configuration on ldap://localhost:9012/ > Using ldapsearch to check that ldap://localhost:9013/ received database... > Using ldapsearch to check that ldap://localhost:9012/ received database... > Running 1 of 1 syncrepl initiation race tests... > Stopping forwarders for add test > Using ldapadd to add 10 entries on provider > Starting forwarders again > Using ldapadd to add 10 more entries on provider > Checking replication to ldap://localhost:9013/ > Checking replication to ldap://localhost:9012/ > Stopping forwarders for add/delete test > Using ldapadd to add 10 entries on provider > Using ldapdelete to delete 10 entries on provider > Starting forwarders again > Using ldapadd to add 10 more entries on provider > Using ldapdelete to delete 10 more entries on provider > Checking replication to ldap://localhost:9013/ > Checking replication to ldap://localhost:9012/ > Stopping forwarders for delete test > Using ldapdelete to delete entries on provider > Starting forwarders again > Using ldapdelete to delete 10 more entries on provider > ldap_result: Can't contact LDAP server (-1) > ldapdelete failed (255)! >>>>>> test061-syncreplication-initiation failed for mdb > (exit 1) > Makefile:309: recipe for target 'mdb-mod' failed > make[2]: *** [mdb-mod] Error 1 > make[2]: Leaving directy %2'/usr/src/michael/openldap-git/re24/openldap/tests' > Makefile:279: recipe for target 'test' failed > make[1]: *** [test] Error 2 > make[1]: Leaving directory '/usr/src/michael/openldap-git/re24/openldap/tests' > Makefile:291: recipe for target 'test' failed > make: *** [test] Error 2 > michael@nb2:/usr/src/michael/openldap-git/re24/openldap> find -name core > ./tests/testrun/prov/core > > > -- -- 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#8257) test061-syncreplication-initiation seg faults
by michael＠stroeder.com 29 Sep '15

29 Sep '15

Full_Name: Version: openSUSE Linux OS: RE24 branch URL: Submission from: (NULL) (84.178.28.66) The current re24 branch seg faults: >>>>> Starting test061-syncreplication-initiation for mdb... Running defines.sh Initializing server configurations Starting provider slapd on ldap://localhost:9011/ Starting forward1 slapd on ldap://localhost:9013/ Starting consumer slapd on ldap://localhost:9012/ Adding schema on ldap://localhost:9011/ Adding backend module on ldap://localhost:9011/... Adding schema on ldap://localhost:9012/ Adding backend module on ldap://localhost:9012/... Adding schema on ldap://localhost:9013/ Adding backend module on ldap://localhost:9013/... Adding database configuration on ldap://localhost:9011/ Populating provider on ldap://localhost:9011/ Adding database configuration on ldap://localhost:9013/ Adding database configuration on ldap://localhost:9012/ Using ldapsearch to check that ldap://localhost:9013/ received database... Using ldapsearch to check that ldap://localhost:9012/ received database... Running 1 of 1 syncrepl initiation race tests... Stopping forwarders for add test Using ldapadd to add 10 entries on provider Starting forwarders again Using ldapadd to add 10 more entries on provider Checking replication to ldap://localhost:9013/ Checking replication to ldap://localhost:9012/ Stopping forwarders for add/delete test Using ldapadd to add 10 entries on provider Using ldapdelete to delete 10 entries on provider Starting forwarders again Using ldapadd to add 10 more entries on provider Using ldapdelete to delete 10 more entries on provider Checking replication to ldap://localhost:9013/ Checking replication to ldap://localhost:9012/ Stopping forwarders for delete test Using ldapdelete to delete entries on provider Starting forwarders again Using ldapdelete to delete 10 more entries on provider ldap_result: Can't contact LDAP server (-1) ldapdelete failed (255)! >>>>> test061-syncreplication-initiation failed for mdb (exit 1) Makefile:309: recipe for target 'mdb-mod' failed make[2]: *** [mdb-mod] Error 1 make[2]: Leaving directy %2'/usr/src/michael/openldap-git/re24/openldap/tests' Makefile:279: recipe for target 'test' failed make[1]: *** [test] Error 2 make[1]: Leaving directory '/usr/src/michael/openldap-git/re24/openldap/tests' Makefile:291: recipe for target 'test' failed make: *** [test] Error 2 michael@nb2:/usr/src/michael/openldap-git/re24/openldap> find -name core ./tests/testrun/prov/core

1 0

Re: (ITS#8221) getting MDB_PAGE_FULL using mdb_cursor_del
by sergej.jurecko＠gmail.com 26 Sep '15

26 Sep '15

> Fixed now in mdb.master, please test and followup with results. Thanks. Yes this fixed it. Thank you. Sergej

1 0

Re: (ITS#8221) getting MDB_PAGE_FULL using mdb_cursor_del
by hyc＠symas.com 26 Sep '15

26 Sep '15

hyc(a)symas.com wrote: > sergej.jurecko(a)gmail.com wrote: >> Full_Name: Sergej Jure&#269;ko >> Version: lmdb 0.9.16 >> OS: osx >> URL: ftp://ftp.openldap.org/incoming/delerror.zip >> Submission from: (NULL) (193.189.172.218) >> >> >> Code and lmdb file is uploaded to ftp. Code is also here: >> https://gist.github.com/SergejJurecko/68979ff6460806581ad5 >> >> If you run the code on the uploaded lmdb file, it will result in MDB_PAGE_FULL >> error out of mdb_cursor_del. >> >> I use dupsorts a lot in my app. Every value in the dupsort has 2 64bit integers >> and 1 u8 in the beginning, which are used in the custom comparison function to >> sort the values. >> >> During normal operation values are added to the end of the dupsort and >> eventually a cleanup operation occurs that deletes unused values. >> >> The example app tries to delete the first value in the dupsort. But it will fail >> the same if it tries to delete the next one instead. > > Thanks for the code and data, it shows the problem pretty clearly. > Unfortunately the solution is less obvious at the moment, still working on it. Fixed now in mdb.master, please test and followup with results. Thanks. -- -- 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#8221) getting MDB_PAGE_FULL using mdb_cursor_del
by hyc＠symas.com 26 Sep '15

26 Sep '15

sergej.jurecko(a)gmail.com wrote: > Full_Name: Sergej Jure&#269;ko > Version: lmdb 0.9.16 > OS: osx > URL: ftp://ftp.openldap.org/incoming/delerror.zip > Submission from: (NULL) (193.189.172.218) > > > Code and lmdb file is uploaded to ftp. Code is also here: > https://gist.github.com/SergejJurecko/68979ff6460806581ad5 > > If you run the code on the uploaded lmdb file, it will result in MDB_PAGE_FULL > error out of mdb_cursor_del. > > I use dupsorts a lot in my app. Every value in the dupsort has 2 64bit integers > and 1 u8 in the beginning, which are used in the custom comparison function to > sort the values. > > During normal operation values are added to the end of the dupsort and > eventually a cleanup operation occurs that deletes unused values. > > The example app tries to delete the first value in the dupsort. But it will fail > the same if it tries to delete the next one instead. Thanks for the code and data, it shows the problem pretty clearly. Unfortunately the solution is less obvious at the moment, still working on it. The situation is this: deleting the record causes the leaf page to become too empty, so it gets merged with a neighboring page - this is no problem. The merge causes its parent branch page to also become too empty, so that is also merged with a neighboring branch page. This is where the problem arises: In a branch page, the key for slot 0 is always empty - it's never stored. So we have two branch pages, each with two nodes, and node 0 of each is essentially zero length. But when merging, we need to store a valid key. We go from page 1, slot 0; page 1, slot 1; and page 2, slot 0; page 2, slot 1 to page 1, slot 0, slot 1, slot 2, slot 3 In this case, we have to retrieve the key corresponding to page 2 slot 0 and store it in page 1 slot 2. In this DB this key is very large, and storing it leaves no room for the last key in slot 3. -- -- 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#8256) Fix install for LMDB
by hyc＠symas.com 25 Sep '15

25 Sep '15

luke.yeager(a)gmail.com wrote: > --001a11473c18e3466e0520962c9f > Content-Type: text/plain; charset=UTF-8 > > Sorry, the URL is: > https://github.com/lukeyeager/lmdb/commit/b0542bc783f2c349d1365a4e647241475… > Thanks, added to mdb.master -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8230) [PATCH] totp: bug fixes and improvements
by hyc＠symas.com 25 Sep '15

25 Sep '15

peter(a)adpm.de wrote: >>> - allow padding to be omitted (totally, not only parts) >> >> Why? > To allow using the keys encoded by other implementations that do > not generate the padding (e.g. Perl's Convert::Base32). > (e.g. in a mass-rollout that sets userPassword using LDIF) We must reject this on security grounds. See RFC3548 Security Considerations. https://tools.ietf.org/html/rfc3548#page-10 Also, as already noted in the code comments, allowing partial bytes would open a subliminal channel allowing information leaks. If Perl's encoder is being so careless then that is a security vulnerability. The other 3 points on this ticket have been committed in master. I consider this ticket resolved. -- -- 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#8256) Fix install for LMDB
by luke.yeager＠gmail.com 25 Sep '15

25 Sep '15

--001a11473c18e3466e0520962c9f Content-Type: text/plain; charset=UTF-8 Sorry, the URL is: https://github.com/lukeyeager/lmdb/commit/b0542bc783f2c349d1365a4e647241475… On Fri, Sep 25, 2015 at 11:02 AM, <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#8256. > > 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#8256) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8256) > > 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=8256 > > Please remember to retain your issue tracking number (ITS#8256) > 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. > > --001a11473c18e3466e0520962c9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Sorry, the URL is:<div><a href=3D"https://github.com/lukey= eager/lmdb/commit/b0542bc783f2c349d1365a4e6472414759e4f04a.patch">https://g= ithub.com/lukeyeager/lmdb/commit/b0542bc783f2c349d1365a4e6472414759e4f04a.p= atch</a><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_= quote">On Fri, Sep 25, 2015 at 11:02 AM, <span dir=3D"ltr"><<a href=3D"= mailto:openldap-its@openldap.org" target=3D"_blank">openldap-its(a)openldap.o= rg</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#8256.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#8256)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org">openldap-its(a)openldap.org</a>?subject=3D(ITS#8256)<br> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D825= 6" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D8256</a><br> <br> Please remember to retain your issue tracking number (ITS#8256)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br></div> --001a11473c18e3466e0520962c9f--

1 0

(ITS#8256) Fix install for LMDB
by luke.yeager＠gmail.com 25 Sep '15

25 Sep '15

Full_Name: Luke Yeager Version: OPENLDAP_REL_ENG_2_5, LMDB_0.9.16 OS: Ubuntu 14.04 URL: Submission from: (NULL) (216.228.112.22) This fixes two small issues. First, if the $(prefix) or $(prefix)/* directories don't exist, they should be created. Second, the shared library is not executable, and should not be marked as such. Patch here: https://github.com/keyeyeager/lmdb/commit/25db4c2ecdfc31653b702cf1e08a09537…

1 0

(ITS#8255) slapd-sock: response parsing in str2result() is broken
by michael＠stroeder.com 24 Sep '15

24 Sep '15

Full_Name: Michael Str.der Version: RE24 OS: URL: Submission from: (NULL) (79.223.48.162) See more information in this thread: http://www.openldap.org/lists/openldap-devel/201509/msg00002.html

1 0

(ITS#8254) RFE: slapd-sock: more request and return parameters
by michael＠stroeder.com 24 Sep '15

24 Sep '15

Full_Name: Michael Str.der Version: HEAD OS: URL: Submission from: (NULL) (79.223.42.126) 1. It would be nice if back-sock listeners could receive more details of an LDAP request: 1.1 TLS client peer certificate would allow to distinguish between a normal bind-DN and the system from which the LDAP request was sent. - either subject-DN like used in authz-regexp configuration directive - issuer-DN+serial like to be used with certificateExactMatch 1.2. Request controls - either as base64-decoded BER (and the listener has to decode it) similar to what RFC 2849 specifys - in some suitable string representation (hard to define) 2. It would be nice if back-sock listeners could return extended response controls to slapd which returns it to the LDAP client. Should be an extra line "control:" with base64-encoded BER value similar to what RFC 2849 specifys

1 0

(ITS#8253) 2.4 Admin guide for syncprov-sessionlog is out of date
by quanah＠openldap.org 23 Sep '15

23 Sep '15

Full_Name: Quanah Gibson-Mount Version: 2.4.x OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) The admin guide for 2.4 section on replication has the description for syncprov-sessionlog from OpenLDAP 2.3, and needs to be updated to reflect current reality of what is tracked (i.e., updated to match the 2.4 man page for syncprov) http://www.openldap.org/doc/admin24/replication.html#Syncrepl, section 18.3.1.2

1 0

Re: ITS#8233
by hyc＠symas.com 23 Sep '15

23 Sep '15

Michael Ströder wrote: > Howard Chu wrote: >> Howard Chu wrote: >>> Michael Ströder wrote: >>>> But then I would expect slapd to remove the backslash(es) used for quoting: >>> >>> Good point. OK, there's some more work needed in here somewhere. >> >> Fixed. Closing this ITS. If you have any other problems regarding this, >> followup to ITS#8233. We don't open new ITSs for unreleased code. > > Sorry, but still I see the same problem with commit > 23953716c76ab36fab7d5f6dea335bf9bdea6323. > > Example from ITS#8251 repeated here: > > In slapd.conf: > > ---------------------------------- snip ---------------------------------- > attributetype ( 1.3.6.1.4.1.5427.1.389.42.3 > DESC 'Test attribute type with \"double quotes\" in DESC' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) > ---------------------------------- snip ---------------------------------- > > Returned via LDAP in subschema subentry (as LDIF): > > ---------------------------------- snip ---------------------------------- > attributeTypes: ( 1.3.6.1.4.1.5427.1.389.42.3 DESC 'Test attribute type with > \"double quotes\" in DESC' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) > ---------------------------------- snip ---------------------------------- True, and irrelevant. This behavior is unchanged from any previous OpenLDAP releases. The regression you reported has been fixed, that is all. > But regarding your comment in [1] I wonder what counts as an "argument"? > Reading the section slapd.conf(5) more carefully it could mean that also all > schema descriptions (containing spaces) count as one argument and therefore > should be enclosed in double quotes (which is not the case also for all > .schema files installed by OpenLDAP). > > Another example is: > > index foo,bar eq,sub > > Does the the config parser handle "foo,bar" and "eq,sub" as two separate > arguments for directive "index"? Does the argument parsing depend on the > configuration directive? Yes, the argument parsing depends on the config directive. All of the schema-related elements (attributetype, objectclass, syntax, ditcontentrule) have their own parsers and (some of) the normal slapd.conf rules don't apply to them. > [1] https://www.openldap.org/its/index.cgi?findid=8251#followup9 > > Ciao, Michael. -- -- 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#8233
by michael＠stroeder.com 23 Sep '15

23 Sep '15

Howard Chu wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> But then I would expect slapd to remove the backslash(es) used for quoting: >> >> Good point. OK, there's some more work needed in here somewhere. > > Fixed. Closing this ITS. If you have any other problems regarding this, > followup to ITS#8233. We don't open new ITSs for unreleased code. Sorry, but still I see the same problem with commit 23953716c76ab36fab7d5f6dea335bf9bdea6323. Example from ITS#8251 repeated here: In slapd.conf: ---------------------------------- snip ---------------------------------- attributetype ( 1.3.6.1.4.1.5427.1.389.42.3 DESC 'Test attribute type with \"double quotes\" in DESC' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) ---------------------------------- snip ---------------------------------- Returned via LDAP in subschema subentry (as LDIF): ---------------------------------- snip ---------------------------------- attributeTypes: ( 1.3.6.1.4.1.5427.1.389.42.3 DESC 'Test attribute type with \"double quotes\" in DESC' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) ---------------------------------- snip ---------------------------------- But regarding your comment in [1] I wonder what counts as an "argument"? Reading the section slapd.conf(5) more carefully it could mean that also all schema descriptions (containing spaces) count as one argument and therefore should be enclosed in double quotes (which is not the case also for all .schema files installed by OpenLDAP). Another example is: index foo,bar eq,sub Does the the config parser handle "foo,bar" and "eq,sub" as two separate arguments for directive "index"? Does the argument parsing depend on the configuration directive? [1] https://www.openldap.org/its/index.cgi?findid=8251#followup9 Ciao, Michael.

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by hyc＠symas.com 22 Sep '15

22 Sep '15

Howard Chu wrote: > Michael Ströder wrote: >> But then I would expect slapd to remove the backslash(es) used for quoting: > > Good point. OK, there's some more work needed in here somewhere. Fixed. Closing this ITS. If you have any other problems regarding this, followup to ITS#8233. We don't open new ITSs for unreleased code. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by ondra＠mistotebe.net 22 Sep '15

22 Sep '15

On Tue, Sep 22, 2015 at 09:01:59AM +0000, geert(a)hendrickx.be wrote: > On Mon, Sep 21, 2015 at 12:28:35 -0700, Quanah Gibson-Mount wrote: > > The rationale was that manageDSAit means let me operate on the raw data and > > disable all side-effects. This is still correct and should remain. > > For clarity I do agree that a control should exist to bypass uniqueness > (and other) constraints. However I think manageDSAit is not the > appropriate control by its definition, and also in practice given the > fact it's set per default by popular client libs. > > Relax Rules seems much more appropriate for this use case, as it's intended > to temporarily relax database constraints, for administrative use only. Yes, Relax control is better for manual bypass. We just need to make sure the original issue that this code was created to address is not reintroduced. ITS#6641 was put up to allow replication to bypass this overlay and anything that was already loaded to one master should happily replicate everywhere else. At that point, manageDSAit was the only way I could find to distinguish an operation coming from syncrepl, it seems that the constraint overlay has a more reliable check so that might be a better idea. Patch to that effect is here: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150922-ITS-8245-unique-rela… Cheers, Ondrej

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by hyc＠symas.com 22 Sep '15

22 Sep '15

Michael Ströder wrote: > Howard Chu wrote: >> Please use plaintext email only. This thread is mostly unreadable due to the >> multiple escapes and other garbage. >> >> michael(a)stroeder.com wrote: >>> You're talking about QQ (single quote ' mentioned in comment as %x27) an= >>> d QS >>> (back-slash mentioned in comment as %x5C). >>> >>> AFAICS the double quote is %x22 and is included in QUTF1. >> >> Yes, DQUOTE is included in QUTF1 but that is not the issue here. The >> slapd.conf(5) syntax says explicitly that double quote is used to enclose >> arguments containing white space. Single quote has no significance to the >> slapd.conf parser. Arguments containing double quote that are meant to be >> taken literally must escape the quote with a backslash. > > But then I would expect slapd to remove the backslash(es) used for quoting: Good point. OK, there's some more work needed in here somewhere. > > In slapd.conf: > > ---------------------------------- snip ---------------------------------- > attributetype ( 1.3.6.1.4.1.5427.1.389.42.3 > DESC 'Test attribute type with \"double quotes\" in DESC' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) > ---------------------------------- snip ---------------------------------- > > Returned via LDAP in subschema subentry (as LDIF): > > attributeTypes: ( 1.3.6.1.4.1.5427.1.389.42.3 DESC 'Test attribute type with > \"double quotes\" in DESC' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.1 > > Ciao, Michael. > -- -- 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#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

Howard Chu wrote: > Please use plaintext email only. This thread is mostly unreadable due to the > multiple escapes and other garbage. > > michael(a)stroeder.com wrote: >> You're talking about QQ (single quote ' mentioned in comment as %x27) an= >> d QS >> (back-slash mentioned in comment as %x5C). >> >> AFAICS the double quote is %x22 and is included in QUTF1. > > Yes, DQUOTE is included in QUTF1 but that is not the issue here. The > slapd.conf(5) syntax says explicitly that double quote is used to enclose > arguments containing white space. Single quote has no significance to the > slapd.conf parser. Arguments containing double quote that are meant to be > taken literally must escape the quote with a backslash. But then I would expect slapd to remove the backslash(es) used for quoting: In slapd.conf: ---------------------------------- snip ---------------------------------- attributetype ( 1.3.6.1.4.1.5427.1.389.42.3 DESC 'Test attribute type with \"double quotes\" in DESC' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) ---------------------------------- snip ---------------------------------- Returned via LDAP in subschema subentry (as LDIF): attributeTypes: ( 1.3.6.1.4.1.5427.1.389.42.3 DESC 'Test attribute type with \"double quotes\" in DESC' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.1 Ciao, Michael.

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by hyc＠symas.com 22 Sep '15

22 Sep '15

Please use plaintext email only. This thread is mostly unreadable due to the multiple escapes and other garbage. michael(a)stroeder.com wrote: > You're talking about QQ (single quote ' mentioned in comment as %x27) an= > d QS > (back-slash mentioned in comment as %x5C). > > AFAICS the double quote is %x22 and is included in QUTF1. Yes, DQUOTE is included in QUTF1 but that is not the issue here. The slapd.conf(5) syntax says explicitly that double quote is used to enclose arguments containing white space. Single quote has no significance to the slapd.conf parser. Arguments containing double quote that are meant to be taken literally must escape the quote with a backslash. -- -- 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#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

This is a cryptographically signed message in MIME format. --------------ms030101070905050603070605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kurt Zeilenga wrote: >=20 >> On Sep 22, 2015, at 10:37 AM, michael(a)stroeder.com wrote: >> >> Kurt Zeilenga wrote: >>> >>>> On Sep 22, 2015, at 12:14 AM, michael(a)stroeder.com wrote: >>>> >>>> Current re24 branch does not accept the following schema description= with double >>>> quote in DESC anymore (which works with 2.4.42) >>> >>> And it shouldn=E2=80=99t, per RFC 4512. >> >> Please be more verbose. >> >> Assuming I'm not mis-reading [1] it allows double quotes in qdstring (= enclosed >> in single quotes). >=20 > You are misreading [1]. the dstring production does not allow the =E2=80= =98 or =E2=80=9C to appear in it. > Instead, \27 is to be used for =E2=80=9C and either \5C or \5c is to be= used for =E2=80=98. You're talking about QQ (single quote ' mentioned in comment as %x27) an= d QS (back-slash mentioned in comment as %x5C). AFAICS the double quote is %x22 and is included in QUTF1. Ciao, Michael. --------------ms030101070905050603070605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDkyMjE4MDIwNFowLwYJKoZIhvcNAQkEMSIEIDB/jT2P8z1vaNnBcy2mGcGUZr6lAPusXEoX FYlfyyEtMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQBSJuATBusD7rXUx/df xf2W9cpi7HJn787NB3MgvRRB/0qXmhNuG2WnSjw/YwAAtixRr3/tK2MHPXMjVphaEm9hiGqp ZWbHiaIvPoBIUwFeM/ehre0x1N8dhpzuK1RQ2OLPij2RKt+ln7XXQOFNXui+v3wug6xAmsuS AueTxwvNo+Pm1syyDwQsnjJpOItDOSEULkEbJ2PVjkcABnNxhKKyZpr79Kofc4mnvImahNsg SufQ+mTd+IX2ILWsXCtU4GJIYpjAuj7UmkXlT4u5LkHlSj9qy6fxS4oZ4keXFWTqEWm/UxzH pLTQu8ILC8CySC8Z4D6g/QPvumDbCbusQkljAAAAAAAA --------------ms030101070905050603070605--

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by kurt＠openldap.org 22 Sep '15

22 Sep '15

Actually I misread it=E2=80=A6 my bad. I was reading QS as =E2=80=9C for some reason=E2=80=A6. must need more = caffeine. Yes, so DESC =E2=80=98=E2=80=9C=E2=80=98 is a legal qdstring. Sorry for the confusion=E2=80=A6 =E2=80=94 Kurt=

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by kurt＠openldap.org 22 Sep '15

22 Sep '15

> On Sep 22, 2015, at 10:37 AM, michael(a)stroeder.com wrote: >=20 > Kurt Zeilenga wrote: >>=20 >>> On Sep 22, 2015, at 12:14 AM, michael(a)stroeder.com wrote: >>>=20 >>> Current re24 branch does not accept the following schema description = with double >>> quote in DESC anymore (which works with 2.4.42) >>=20 >> And it shouldn=E2=80=99t, per RFC 4512. >=20 > Please be more verbose. >=20 > Assuming I'm not mis-reading [1] it allows double quotes in qdstring = (enclosed > in single quotes). You are misreading [1]. the dstring production does not allow the =E2=80=98= or =E2=80=9C to appear in it. Instead, \27 is to be used for =E2=80=9C and either \5C or \5c is to be = used for =E2=80=98. =E2=80=94 Kurt=

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

Kurt Zeilenga wrote: > >> On Sep 22, 2015, at 12:14 AM, michael(a)stroeder.com wrote: >> >> Current re24 branch does not accept the following schema description with double >> quote in DESC anymore (which works with 2.4.42) > > And it shouldn’t, per RFC 4512. Please be more verbose. Assuming I'm not mis-reading [1] it allows double quotes in qdstring (enclosed in single quotes). [1] https://tools.ietf.org/html/rfc4512#section-4.1 Note that this is not a schema file I've created and which I could change. This is the CIM schema provided as is since years. Ciao, Michael.

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by kurt＠openldap.org 22 Sep '15

22 Sep '15

--Apple-Mail=_EF88B354-9156-4D3C-9559-63AB3F05C465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 22, 2015, at 12:14 AM, michael(a)stroeder.com wrote: >=20 > Current re24 branch does not accept the following schema description = with double > quote in DESC anymore (which works with 2.4.42) And it shouldn=E2=80=99t, per RFC 4512. =E2=80=94 Kurt= --Apple-Mail=_EF88B354-9156-4D3C-9559-63AB3F05C465 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On Sep 22, 2015, at 12:14 AM, <a = href=3D"mailto:michael@stroeder.com" class=3D"">michael(a)stroeder.com</a> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: auto; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: auto; word-spacing: = 0px; -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">Current re24 branch does not accept the = following schema description with double</span><br style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">quote in DESC anymore (which works with = 2.4.42)</span></div></blockquote></div><div class=3D""><br = class=3D""></div><div class=3D"">And it shouldn=E2=80=99t,  per RFC = 4512.</div><div class=3D""><br class=3D""></div><div class=3D"">=E2=80=94 = Kurt</div></body></html>= --Apple-Mail=_EF88B354-9156-4D3C-9559-63AB3F05C465--

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by geert＠hendrickx.be 22 Sep '15

22 Sep '15

On Mon, Sep 21, 2015 at 12:28:35 -0700, Quanah Gibson-Mount wrote: > The rationale was that manageDSAit means let me operate on the raw data and > disable all side-effects. This is still correct and should remain. For clarity I do agree that a control should exist to bypass uniqueness (and other) constraints. However I think manageDSAit is not the appropriate control by its definition, and also in practice given the fact it's set per default by popular client libs. Relax Rules seems much more appropriate for this use case, as it's intended to temporarily relax database constraints, for administrative use only. > However, an option could be added to the module to disable this control > specifically for this overlay. No, then I would need to change the server config to disable that option each time I'd wish to temporarily bypass the constraint, instead of using another dedicated control for that (which would need no disable option). Geert -- geert.hendrickx.be :: geert(a)hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

This is a cryptographically signed message in MIME format. --------------ms040301090601090607070001 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Maybe a regression caused by fix for ITS#8233? >=20 > I don't consider this a regression, the error message is correct. So you don't consider this to be a bug at all? Questions: Is the attribute type desciption syntactically incorrect? I don't think so because the double quote is correctly enclosed in single= quotes. Isn't it admirable that 2.4.43 will also parse correct attribute type desciptions just like 2.4.42 did? Ciao, Michael. --------------ms040301090601090607070001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDkyMjA4MDkwOVowLwYJKoZIhvcNAQkEMSIEIP8a4Fv1HL/ocxij2rGuMQu/vKyamOnfl72t MbYyldeWMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQAC8Rli/OWS6xnYDqYe REyK9yu1teuld+BgI5gZv71k+RNPelUQFxe/BcoJUAOc9lUoUXZjH/37i2F+9eE7/w2WiasF kf3K/2E2BeNps4hxPniqDSIQYLtixB1RbSaNxEpgtFO8CcDSmJa04fzh3Wj14ec6ivPT0qeE OHmDfXMmcf8WoqEqx5eAZi2/G2Tk8uzIzGVqRtoVxhP6eIesCZjBielYs8KP/v1oEM2CYK9K X5NkyxqdFxhBdCRmKIirl/JNH0nZJqA2oV1e1F2Jo3LxwgPUfS4Kr3VELScoNcW/NP28GNUh f5o0Ak8ZOhQ4pNKJbm1leBzhgztG1AkkQ7MMAAAAAAAA --------------ms040301090601090607070001--

1 0

Re: (ITS#8251) slapd fails schema parsing with double quotes in DESC
by hyc＠symas.com 22 Sep '15

22 Sep '15

michael(a)stroeder.com wrote: > Maybe a regression caused by fix for ITS#8233? I don't consider this a regression, the error message is correct. -- -- 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#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

Maybe a regression caused by fix for ITS#8233?

1 0

(ITS#8251) slapd fails schema parsing with double quotes in DESC
by michael＠stroeder.com 22 Sep '15

22 Sep '15

Full_Name: Michael Str.der Version: RE24 branch OS: openSUSE Linux URL: Submission from: (NULL) (79.223.42.239) Current re24 branch does not accept the following schema description with double quote in DESC anymore (which works with 2.4.42): attributetype ( 1.3.6.1.4.1.412.100.2.2.119 NAME 'dlmNameFormat' DESC 'The System object and its derivatives are Top Level Objects of CIM. They provide the scope for numerous components. Having unique System keys is required. A heuristic can be defined in individual System subclasses to attempt to always generate the same System Name Key. The NameFormat property identifies how the System name was generated, using the subclass" heuristic.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE EQUALITY caseIgnoreMatch ) Starting slapd outputs this message: 5600fed2 /home/michael/ftp/Linux/Networking/LDAP/OpenLDAP/schema/cim_core-2.5.schema: line 136: unterminated quoted string "subclass heuristic.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE EQUALITY caseIgnoreMatch ) "

1 0

Re: (ITS#8250) Allowing transaction to be created in the reset state
by rouzier＠gmail.com 21 Sep '15

21 Sep '15

--047d7bd76db0ae5e3d0520480218 Content-Type: text/plain; charset=UTF-8 Sorry I did not retest the patch with after rebasing. Here is the new patch and diff https://github.com/rouzier/openldap/compare/7e476e4983cfba45cefe793b8bd6e13… https://github.com/rouzier/openldap/compare/7e476e4983cfba45cefe793b8bd6e13… On Sat, Sep 19, 2015 at 2:44 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#8250. > > 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#8250) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8250) > > 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=8250 > > Please remember to retain your issue tracking number (ITS#8250) > 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. > > --047d7bd76db0ae5e3d0520480218 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Sorry I did not retest the patch with after rebasing.= </div><div>Here is the new patch and diff</div><div><br></div><a href=3D"ht= tps://github.com/rouzier/openldap/compare/7e476e4983cfba45cefe793b8bd6e13c4= 86b3989...feature/txn-begin-reset.patch">https://github.com/rouzier/openlda= p/compare/7e476e4983cfba45cefe793b8bd6e13c486b3989...feature/txn-begin-rese= t.patch</a><div><br><div><a href=3D"https://github.com/rouzier/openldap/com= pare/7e476e4983cfba45cefe793b8bd6e13c486b3989...feature/txn-begin-reset.dif= f">https://github.com/rouzier/openldap/compare/7e476e4983cfba45cefe793b8bd6= e13c486b3989...feature/txn-begin-reset.diff</a><br></div></div><div><br></d= iv></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, = Sep 19, 2015 at 2:44 PM, <span dir=3D"ltr"><<a href=3D"mailto:openldap-= its(a)openldap.org" target=3D"_blank">openldap-its(a)openldap.org</a>></span= > wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#8250.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#8250)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org">openldap-its(a)openldap.org</a>?subject=3D(ITS#8250)<br> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D825= 0" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D8250</a><br> <br> Please remember to retain your issue tracking number (ITS#8250)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br></div> --047d7bd76db0ae5e3d0520480218--

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by michael＠stroeder.com 21 Sep '15

21 Sep '15

This is a cryptographically signed message in MIME format. --------------ms070405030901070403010409 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable quanah(a)zimbra.com wrote: > Per discussion with Howard & Halvard, >=20 > The rationale was that manageDSAit means let me operate on the raw data= and=20 > disable all side-effects. This is still correct and should remain.=20 > However, an option could be added to the module to disable this control= =20 > specifically for this overlay. Why not just change to use the Relax Rules Control instead? Especially since it already requires manage privilege. Which use-case would not work anymore when using Relax Rules Control inst= ead of manageDSAit control? Do you expect any unwanted side-effects? IIRC the Relax Rules (formerly known as Manage DIT) control was simply no= t yet invented when Pierangelo implemented this. Ciao, Michael. --------------ms070405030901070403010409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDkyMTIwMTIwN1owLwYJKoZIhvcNAQkEMSIEIJWYu87v6+YtojTp06oj2bLHg2pHOysNOSzM 0ip0IgNgMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQA7H/eMKVLo60pmewMT bVp3c2Ob7GaMp5rmexRvLEYCGyyflE10MgnEO6e24T0BiWTiOj7mNhsrZ+Phys1JDWyOXGZb 6Zfah4FKy7lFu3hSMVQ7e9EqWAys5GhpyRu/LiCbCC2ECzOsLL2fDNFa2UgMoWN4TgnX/nzH UXM4WT8EDUwOyAXBoC+PY5HJj3I8x9+uRKvxA5JMkZXYv7jnjw2fmhvIAvIVrlQ0AgyIIsPK 1SvKdY974crYb8FPv+9Wmqw9LU4u9zLY5B9/RTmCAOon4AUUMZJRhb6oMSTMyslaotFeHa3a X3KauocBWxUpsjvOX+tTD4hyp/yfSotkuRBdAAAAAAAA --------------ms070405030901070403010409--

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by quanah＠zimbra.com 21 Sep '15

21 Sep '15

--On Monday, September 14, 2015 8:38 AM +0000 geert(a)hendrickx.be wrote: > Full_Name: Geert Hendrickx > Version: 2.4.42 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.123.14.2) > > > Currently the ManageDsaIt control allows bypassing attribute uniqueness > constraints as implemented by slapo-unique(5). This seems inappropriate > as the ManageDsaIt control (RFC 3296) is intended for managing referral > objects. Also it is set by default by certain clients (specifically Java > JNDI) which makes uniqueness constraints practically useless with such > clients. > > The newer Relax Rules control (draft-zeilenga-ldap-relax) seems much more > appropriate for this use case, please consider using it instead. The > simple pchch below works for me, but I haven't tested its interaction with > replication. Hi Geert, Per discussion with Howard & Halvard, The rationale was that manageDSAit means let me operate on the raw data and disable all side-effects. This is still correct and should remain. However, an option could be added to the module to disable this control specifically for this overlay. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8250) Allowing transaction to be created in the reset state
by rouzier＠gmail.com 19 Sep '15

19 Sep '15

Full_Name: James Rouzier Version: OS: URL: https://github.com/rouzier/openldap/commit/54f60e7eb699778197fa154953fccfa8… Submission from: (NULL) (70.81.32.80) This patch allows mdb_txn_begin to create a transaction in the reset state. So instead of doing this. mdb_txn_begin(env, NULL, MDB_READONLY,&txn); mdb_txn_reset(txn); You now can just do this. mdb_txn_begin(env, NULL, MDB_READONLY| MDB_TXNRESET,&txn); You can view the patch here https://github.com/rouzier/openldap/commit/54f60e7eb699778197fa154953fccfa8… The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by James Rouzier <rouzier(a)gmail.com>. I have not assigned rights and/or interest in this work to any party.

1 0

(ITS#8249) add search response to back-null
by hyc＠openldap.org 17 Sep '15

17 Sep '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.251.255.12) Submitted by: hyc Sometimes we need a simple backend like back-null, but which returns at least 1 entry on search requests.

1 0

(ITS#8248) misleading information in manpage about the use of the logfile option
by steffen.hofmann-credner＠bsi.bund.de 17 Sep '15

17 Sep '15

Full_Name: Steffen Hofmann Version: 2.4.42 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:198:5a1:200:10ea:bdac:f2f:c3b8) Misleading information in slapd.conf: an option _logfile_ is described in slapd.conf: "Specify a file for recording debug log messages. [...]" unfortunately it is not clear, what are "debug log messages". Obviously it is not " debugging statements and operation statistics" which can be controlled by the loglevel option. To be honest, I have no clue what the option is for. The only result I got in using this, what a new, empty log file. My, and (by google a few other, too) expected that the logfile option specify the file for the debugging statements.

1 0

(ITS#8247) ru_RU.UTF-8 search problem
by oleg.a.smirnov＠gmail.com 17 Sep '15

17 Sep '15

Full_Name: Oleg Smirnov Version: 2.4.42 OS: linux ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.147.131.107) When searching for Russian words confused Tupper And tolower functions: See to end of the select, russian word wrote in low case: "upper(...) like '%low case%'" 55f9ebc5 Constructed query: SELECT DISTINCT ldap_entries.id,ldapx_persons.id,text('inetOrgPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ldapx_persons WHERE ldapx_persons.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND upper(ldap_entries.dn) LIKE upper('%'||?) AND ldapx_persons.lang=0 AND (upper(ldapx_persons.surname) LIKE '%бугров%')

1 0

(ITS#8246) defining multiple frontend DBs should probably not be allowed
by ryan＠openldap.org 16 Sep '15

16 Sep '15

Full_Name: Ryan Tandy Version: 2.4, master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan In #openldap, IsoLinCHiP noted that the following config works as intended, and asked whether it's supported: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by * +0 break dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config dn: olcDatabase={1}frontend,cn=config objectClass: olcDatabaseConfig%obobjectClass: olcFrontendConfig olcDatabase: {1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=subschema" by * read olcAccess: {2}to dn.subtree="dc=de" attrs=userPassword,userPKCS12 by * auth dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /usr/local/openldap/var/openldap-data olcRootDN: cn=admin,cn=config olcSuffix: dc=de The current behaviour is that the additional ACLs on olcDatabase={1}frontend get appended to the frontendDB ACL just as if they'd been defined on olcDatabase={-1}frontend. Behaviour for other attributes varies: some are merged with earlier values, or overwrite them; others are rejected. It seems to me that defining a second frontend is neither supported, nor to be depended upon, and therefore should probably be explicitly disallowed. Am I right?

1 0

(ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by geert＠hendrickx.be 14 Sep '15

14 Sep '15

Full_Name: Geert Hendrickx Version: 2.4.42 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.123.14.2) Currently the ManageDsaIt control allows bypassing attribute uniqueness constraints as implemented by slapo-unique(5). This seems inappropriate as the ManageDsaIt control (RFC 3296) is intended for managing referral objects. Also it is set by default by certain clients (specifically Java JNDI) which makes uniqueness constraints practically useless with such clients. The newer Relax Rules control (draft-zeilenga-ldap-relax) seems much more appropriate for this use case, please consider using it instead. The simple pchch below works for me, but I haven't tested its interaction with replication. Geert --- servers/slapd/overlays/unique.c 2015-08-14 17:25:28.000000000 +0200 +++ servers/slapd/overlays/unique.c 2015-09-07 22:00:44.217833199 +0200 @@ -1038,9 +1038,8 @@ Debug(LDAP_DEBUG_TRACE, "==> unique_add <%s>\n", op->o_req_dn.bv_val, 0, 0); - /* skip the checks if the operation has manageDsaIt control in it - * (for replication) */ - if ( op->o_managedsait > SLAP_CONTROL_IGNORED + /* skip the checks if the operation has relax control in it */ + if ( op->o_relax > SLAP_CONTROL_IGNORED && access_allowed ( op, op->ora_e, slap_schema.si_ad_entry, NULL, ACL_MANAGE, NULL ) ) { @@ -1170,9 +1169,8 @@ Debug(LDAP_DEBUG_TRACE, "==> unique_modify <%s>\n", op->o_req_dn.bv_val, 0, 0); - /* skip the checks if the operation has manageDsaIt control in it - * (for replication) */ - if ( op->o_managedsait > SLAP_CONTROL_IGNORED + /* skip the checks if the operation has relax control in it */ + if ( op->o_relax > SLAP_CONTROL_IGNORED && overlay_entry_get_ov(op, &op->o_req_ndn, NULL, NULL, 0, &e, on) == LDAP_SUCCESS && e && access_allowed ( op, e, @@ -1301,9 +1299,8 @@ Debug(LDAP_DEBUG_TRACE, "==> unique_modrdn <%s> <%s>\2222, op->o_req_dn.bv_val, op->orr_newrdn.bv_val, 0); - /* skip the checks if the operation has manageDsaIt control in it - * (for replication) */ - if ( op->o_managedsait > SLAP_CONTROL_IGNORED + /* skip the checks if the operation has relax control in it */ + if ( op->o_relax > SLAP_CONTROL_IGNORED && overlay_entry_get_ov(op, &op->o_req_ndn, NULL, NULL, 0, &e, on) == LDAP_SUCCESS && e && access_allowed ( op, e, --- doc/man/man5/slapo-unique.5 2015-08-14 17:25:28.000000000 +0200 +++ doc/man/man5/slapo-unique.5 2015-09-14 09:22:26.242624918 +0200 @@ -162,7 +162,7 @@ maximum flexibility in meeting site-specific requirements. .LP Replication and operations with -.B manageDsaIt +.B relax control are allowed to bypass this enforcement. It is therefore important that all servers accepting writes have this overlay configured in order to maintain uniqueness in a replicated DIT.

1 0

(ITS#8244) back-ldap entry_get is wrong
by hyc＠openldap.org 14 Sep '15

14 Sep '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.236.74) Submitted by: hyc The be_entry_get() entry point is only used for internal operations, not client-initiated operations. Currently it propagates client-provided controls through, but they don't belong there. If be_entry_get is invoked due to an ACL evaluation, and the original client operation was a syncrepl search, and the remote server honors the syncrepl control, then this query may hang because ldap_back_entry_get() doesn't expect to handle any Intermediate responses. Worse, if the control requested RefreshAndPersist, then additional responses may pile up on the session as the remote server sends persist updates.

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com 12 Sep '15

12 Sep '15

Michael Ströder wrote: > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> On 12/09/15 16:24, michael(a)stroeder.com wrote: >>>> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not >>>> help. slapd still crashes when hitting the assert. >>> >>> Yes, portable.h #undefs it by default. OpenLDAP has always conflated >>> logging, debug output and asserts behind LDAP_DEBUG. We've been saying >>> for some time that we really ought to do something about that someday... >> >> Yes, and that's more obviously a bug that we can fix. > > Is it an easy fix? Not for 2.4. > I think that in opposite to the OpenLDAP project most people out there > consider this to be a really serious bug to be fixed really soon. > For now with my own builds I apply the patch removing the assert statement. > But I wonder how many asserts statements are in the code which can be hit by > invalid input leading to a crash. Given the lack of OpenLDAP documentation about NDEBUG I have re-reverted my previous revert. The patch has been reinstated. >> Every use of assert is "assert(the code is correct)" - but that often depends >> on dynamic state, not just the statically written code. > > Yes, dynamic state including invalid input. But IMO "assert(the code is > correct)" should never be hit no matter how bad the input was. And it should > definitely not crash the server (with system's ressource limits being a > unavoidable exception). Rephrasing: The meaning of the statement "the code is > correct" should also include "invalid input is properly handled as error" - no > matter what. In this particular case the code already handles the error perfectly well without the assert, so the assert doesn't serve any useful purpose. -- -- 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#8240) OpenLDAP ber_get_next denial of service vulnerability
by michael＠stroeder.com 12 Sep '15

12 Sep '15

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> On 12/09/15 16:24, michael(a)stroeder.com wrote: >>> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not >>> help. slapd still crashes when hitting the assert. >> >> Yes, portable.h #undefs it by default. OpenLDAP has always conflated >> logging, debug output and asserts behind LDAP_DEBUG. We've been saying >> for some time that we really ought to do something about that someday... > > Yes, and that's more obviously a bug that we can fix. Is it an easy fix? I think that in opposite to the OpenLDAP project most people out there consider this to be a really serious bug to be fixed really soon. For now with my own builds I apply the patch removing the assert statement. But I wonder how many asserts statements are in the code which can be hit by invalid input leading to a crash. >> Even ignoring that, demanding -NDEBUG is backwards in so many ways: >> >> Using C's features like <assert.h> is not the user's job, it's >> OpenLDAP's (i.e. configure and portable.hin). The person building >> OpenLDAP might not even be a C programmer who knows about the C >> language quirk that it has a feature makes errors crash by default. > > It is standard practice in C code. assert() and NDEBUG are part of the C > standard. A person who doesn't know C has no business building the code. > Certainly the libraries are of no use to them if they're not C programmers > already. This is a black-and-white-only statement which does not meet 90% of the cases out there. >> A simple "./configure --prefix=/whatever" ought to be a reasonable way >> to build OpenLDAP, like with most other packages. There are >> installation instructions and they do not mention NDEBUG. I strongly concur with Hallvard here. > Every use of assert is "assert(the code is correct)" - but that often depends > on dynamic state, not just the statically written code. Yes, dynamic state including invalid input. But IMO "assert(the code is correct)" should never be hit no matter how bad the input was. And it should definitely not crash the server (with system's ressource limits being a unavoidable exception). Rephrasing: The meaning of the statement "the code is correct" should also include "invalid input is properly handled as error" - no matter what. Ciao, Michael.

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com 12 Sep '15

12 Sep '15

h.b.furuseth(a)usit.uio.no wrote: > On 12/09/15 16:24, michael(a)stroeder.com wrote: >> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not >> help. slapd still crashes when hitting the assert. > > Yes, portable.h #undefs it by default. OpenLDAP has always conflated > logging, debug output and asserts behind LDAP_DEBUG. We've been saying > for some time that we really ought to do something about that someday... Yes, and that's more obviously a bug that we can fix. > Even ignoring that, demanding -NDEBUG is backwards in so many ways: > > Using C's features like <assert.h> is not the user's job, it's > OpenLDAP's (i.e. configure and portable.hin). The person building > OpenLDAP might not even be a C programmer who knows about the C > language quirk that it has a feature makes errors crash by default. It is standard practice in C code. assert() and NDEBUG are part of the C standard. A person who doesn't know C has no business building the code. Certainly the libraries are of no use to them if they're not C programmers already. > A simple "./configure --prefix=/whatever" ought to be a reasonable way > to build OpenLDAP, like with most other packages. There are > installation instructions and they do not mention NDEBUG. > > In particular since this isn't even about catching a bug in OpenLDAP, > but in the input. If someone wants to crash-debug the input to slapd, > let him #define something when building slapd. You could replace the > assert() with debug_assert() or something. The same goes for any > other assert which doesn't mean "assert(the code is correct)". Every use of assert is "assert(the code is correct)" - but that often depends on dynamic state, not just the statically written code. Just like "assert(SOCKBUF_VALID(sb))" or whatever else. That is the case for the assert in question here. -- -- 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#7964) overlay rwm escape issue with more the 9 rules / rewrite statements
by ryan＠nardis.ca 12 Sep '15

12 Sep '15

Hi Michael, On Sat, Sep 12, 2015 at 02:38:44PM +0200, Michael Str=F6der wrote: >I wonder whether that caused a regression parsing multi-line DESC '..' in >schema descriptions. > >Up to now I could load this but it does not work with current RE24 branch: > >objectClass ( 1.3.6.1.4.1.412.100.2.1.3.2 NAME 'dlm1ManagedSystemElement' > DESC 'ManagedSystemElement is the base class for the > System Element hierarchy. Membership Criteria: Any > distinguishable component of a System is a candidate > for inclusion in this class. Examples: software > components, such as files; and devices, such as disk > drives and controllers, and physical components such > as chips and cards.' > SUP dlm1ManagedElement ABSTRACT > MAY ( dlmInstallDate $ dlmName $ dlmStatus ) ) > >This is not schema generated by me. A schema with the above DESC (including line breaks), and SUP top=20 ABSTRACT MAY description, is working fine for me on RE24 (as of c5b4cd6)=20 configured with "--disable-bdb --disable-hdb --enable-rwm". I tested embedding it directly in slapd.conf, including via 'include=20 test.schema', and ldapadd'ing an LDIF version into cn=3Dconfig at runtime. = =20 (admittedly the last is probably not relevant, since it becomes one long=20 logical LDIF line.) Can you provide some more details about the failure you see? Glancing at the RE24 log, I'd look at ITS#8233 as the change most likely=20 to be related, but can't say anything for sure without a reproducible=20 test case. thanks, Ryan

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by h.b.furuseth＠usit.uio.no 12 Sep '15

12 Sep '15

I wrote: > If someone wants to crash-debug the input to slapd, > let him #define something when building slapd. You could replace the > assert() with debug_assert() or something. The same goes for any > other assert which doesn't mean "assert(the code is correct)". Look at LDAP_MEMORY_DEBUG and its doc in liblber/memory.c, for example. With the note "* ... If LDAP_MEMORY_DEBUG & 2 is true, * that includes asserts known to break both slapd and current clients."

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by h.b.furuseth＠usit.uio.no 12 Sep '15

12 Sep '15

On 12/09/15 16:24, michael(a)stroeder.com wrote: > I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not > help. slapd still crashes when hitting the assert. Yes, portable.h #undefs it by default. OpenLDAP has always conflated logging, debug output and asserts behind LDAP_DEBUG. We've been saying for some time that we really ought to do something about that someday... Even ignoring that, demanding -NDEBUG is backwards in so many ways: Using C's features like <assert.h> is not the user's job, it's OpenLDAP's (i.e. configure and portable.hin). The person building OpenLDAP might not even be a C programmer who knows about the C language quirk that it has a feature makes errors crash by default. A simple "./configure --prefix=/whatever" ought to be a reasonable way to build OpenLDAP, like with most other packages. There are installation instructions and they do not mention NDEBUG. In particular since this isn't even about catching a bug in OpenLDAP, but in the input. If someone wants to crash-debug the input to slapd, let him #define something when building slapd. You could replace the assert() with debug_assert() or something. The same goes for any other assert which doesn't mean "assert(the code is correct)".

1 0

(ITS#8243) LMDB Makefile bug
by jiayq＠eecs.berkeley.edu 12 Sep '15

12 Sep '15

Full_Name: Yangqing Jia Version: OS: Ubuntu 12.04 URL: Submission from: (NULL) (2601:646:8f00:2700:ac83:6009:7765:c6b0) In the Makefile of LMDB, the installation part reads as follows: install: $(ILIBS) $(IPROGS) $(IHDRS) for f in $(IPROGS); do cp $$f $(DESTDIR)$(prefix)/bin; done for f in $(ILIBS); do cp $$f $(DESTDIR)$(prefix)/lib; done for f in $(IHD%2); do cp $$f $(DESTDIR)$(prefix)/include; done for f in $(IDOCS); do cp $$f $(DESTDIR)$(prefix)/man/man1; done This usually works OK, but it silently asumes that $(DESTDIR)$(prefix)/bin and other folders exist. While it works in most cases, if the folders do not exist, what follows is that the installation script generates FILES instead of FOLDERS named bin, lib, include and man1 respectively. We should add "mkdir -p" commands in the installation part to fix this.

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by michael＠stroeder.com 12 Sep '15

12 Sep '15

hyc(a)symas.com wrote: > Our patch response was too hasty. There is no OpenLDAP bug here, the real > issue is production binaries being built with asserts enabled instead of > compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. > Closing this ITS, not an OpenLDAP bug. I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not help. slapd still crashes when hitting the assert. Ciao, Michael.

1 0

Re: (ITS#7964) overlay rwm escape issue with more the 9 rules / rewrite statements
by michael＠stroeder.com 12 Sep '15

12 Sep '15

This is a cryptographically signed message in MIME format. --------------ms030300010006010903020301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ryan Tandy wrote: > Fixed in git master by removing the extra escaping on insert. You will = have to > adjust your rules to use a single backslash instead of two. I wonder whether that caused a regression parsing multi-line DESC '..' in= schema descriptions. Up to now I could load this but it does not work with current RE24 branch= : objectClass ( 1.3.6.1.4.1.412.100.2.1.3.2 NAME 'dlm1ManagedSystemElement'= DESC 'ManagedSystemElement is the base class for the System Element hierarchy. Membership Criteria: Any distinguishable component of a System is a candidate for inclusion in this class. Examples: software components, such as files; and devices, such as disk drives and controllers, and physical components such as chips and cards.' SUP dlm1ManagedElement ABSTRACT MAY ( dlmInstallDate $ dlmName $ dlmStatus ) ) This is not schema generated by me. Ciao, Michael. --------------ms030300010006010903020301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDkxMjEyMzg0NFowLwYJKoZIhvcNAQkEMSIEIDrXZa1NywG8SrP5ntFoYlltABMT8tTiZXDf 2VaTDJRiMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQAeCC2CW5txoCJMgggs UcEJA2eZPOXbq3XU1XrDvO6tsBacNPuuIvJ/rbcjBYgwy/aTcQfbgeLhgNKeigtYtGIMMAo2 lKohLrccMl7ZlQ+ysZDu8gzK715y9z+SZqsz6/82zK2o1UBRcZpKKMDJjV3fUFc+AoS9mPo5 Vz/P4an5x5YckvOaHb6a7El6gvEbTRbVTwPJldlSo6PIcGDf2Jk/vEDDmBS59VK/+mgaHp7R JwYHYQmSxCYBWuR9JBAB0maoQMJf9tEUMh9CQiwj8CVko92ov6xIOHRfDXOuCDZZ4tdjOPDC lqNaoruOVzuULGhzW9wo5oabo19dgb4pOuI6AAAAAAAA --------------ms030300010006010903020301--

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com 12 Sep '15

12 Sep '15

denis.andzakovic(a)security-assessment.com wrote: > Full_Name: Denis Andzakovic > Version: 2.4.42 > OS: Debian 8 > URL: > Submission from: (NULL) (2402:6000:110:a01:743b:8319:1f96:bd89) > > > OpenLDAP ber_get_next Denial of Service > Affected Versions: OpenLDAP <= 2.4.42 > +----------+ > | Solution | > +----------+ > Ensure that data received from untrusted sources is not able to trigger > conditions resulting in the server crashing. In this specific instance, the > NDEBUG macro should be defined before the inclusion of assert.h by default, > requiring a specific compile time alteration to enable debug. Our patch response was too hasty. There is no OpenLDAP bug here, the real issue is production binaries being built with asserts enabled instead of compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. Closing this ITS, not an OpenLDAP bug. -- -- 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#8240
by hyc＠symas.com 11 Sep '15

11 Sep '15

michael(a)stroeder.com wrote: > Hmm...wouldn't this ITS justify some quick security release 2.4.43? For the umpteenth time - the Project only considers unintended information disclosures or remote code execution flaws as security issues. Neither applies here. -- -- 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