- openldap-bugs - openldap.org

(ITS#8260) Test "test062-config-delete" occasionally runs into segmentation fault
by hguo＠suse.com 01 Oct '15

01 Oct '15

Full_Name: Howard Guo Version: master-94d6581b50fa2d877cf4a1e20ca6766454094ef8 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.135.221.2) The test case "test062-config-delete" occasionally runs into segfault when running with BDB backend. The chance of segfault happening is about once every 200 runs. The version of OpenLDAP is post-2.4.42 master checked out at revision 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make. The operating system is openSUSE Tumbleweed running on kernel 4.1.6. Here is the GDB conversation with a captured core dump file: Core was generated by `/home/howard/qa_test_openldap2/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000055e606fed253 in syncprov_op_abandon (op=0x7f7aa15498a0, rs=0x7f7aa15496e0) at syncprov.c:1156 1156 if ( so->s_op->o_connid == op->o_connid && (gdb) l 1151 syncprov_info_t *si = on->on_bi.bi_private; 1152 syncops *so, **sop; 1153 1154 ldap_pvt_thread_mutex_lock( &si->si_ops_mutex ); 1155 for ( sop=&si->si_ops; (so = *sop); sop = &(*sop)->s_next ) { 1156 if ( so->s_op->o_connid == op->o_connid && 1157 so->s_op->o_msgid == op->orn_msgid ) { 1158 so->s_op->o_abandon = 1; 1159 *sop = so->s_next; 1160 break; (gdb) info locals on = <optimized out> si = 0x7f7a94104990 so = 0x7f7a94103f30 sop = 0x7f7a94104990 (gdb) print so->s_op->o_hdr Cannot access memory at address 0x6172757463757274 Please let me know how I may assist further with debugging.

1 0

Re: (ITS#8259) LMDB utilities print usage incorrectly
by hyc＠symas.com 30 Sep '15

30 Sep '15

jpmens(a)gmail.com wrote: > Full_Name: Jan-Piet Mens > Version: LMDB 0.9.16 > OS: OSX, Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a02:908:b41:38e0:241a:be7c:787f:620) > > > LMDB's utilities (mdb_stat, mdb_copy, etc) incorrectly specify that dbpath > (envpath) comes before options. > > $ ./mdb_stat jp -a > usage: ./mdb_stat dbpath [-V] [-n] [-e] [-r[r]] [-f[f[f]]] [-a|-s subdb] > > $ ./mdb_stat -a jp > Status of Main DB > ... > > This also requires a documentation update in the man pages. Fixed in mdb.master and mdb.RE/0.9 -- -- 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#8259) LMDB utilities print usage incorrectly
by jpmens＠gmail.com 30 Sep '15

30 Sep '15

Full_Name: Jan-Piet Mens Version: LMDB 0.9.16 OS: OSX, Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:908:b41:38e0:241a:be7c:787f:620) LMDB's utilities (mdb_stat, mdb_copy, etc) incorrectly specify that dbpath (envpath) comes before options. $ ./mdb_stat jp -a usage: ./mdb_stat dbpath [-V] [-n] [-e] [-r[r]] [-f[f[f]]] [-a|-s subdb] $ ./mdb_stat -a jp Status of Main DB ... This also requires a documentation update in the man pages.

1 0

Re: (ITS#8258) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by hyc＠symas.com 30 Sep '15

30 Sep '15

steven.lang(a)hgst.com wrote: > Full_Name: Steven Lang > Version: LMDB 0.9.16 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/steven-lang-150929.c > Submission from: (NULL) (199.255.44.5) > > > While doing some testing using randomized key and data lengths and random puts > and deletes, I found a situation in which mdb_cursor_del(...) followed by > mdb_cursor_get(..., MDB_NEXT) causes an error: > > mdb.c:5726: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() > Aborted > > After a little debugging I was able to isolate what the cause was and produce a > simple program to reproduce the issue; during the re-balance following a delete, > it would try to move a node from the first child of the root page to the second. > If the node it moves has a key longer than the second node in the root page, and > the new key doesn't fit, it will split the root page. As a result, by deleting a > node, the tree becomes deeper. > > However, the cursor only checks and compensates for the tree becoming shallower. > So now the cursor was pointing to a branch page rather than a leaf page. Any > further cursor operations fail. (Trying to do a MDB_SET, MDB_SET_RANGE, etc will > silently fail at this point, while MDB_NEXT and possibly MDB_PREV will assert.) > > The latest head with the fix for ITS#8221 changes the behavior slightly, due to > the different arrangement of the tree with the less aggressive merging. However, > it still fails. > > Attached is a program which fills a DB, then deletes keys until it asserts. Thanks for the report. Our alternate approach to solve #8221 was to check the page fill factor including the (usually omitted) key #0 size; we didn't go that way because it was slightly more processing. But given this bug, it seems that's the only way to go. -- -- 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#8258) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by steven.lang＠hgst.com 30 Sep '15

30 Sep '15

Full_Name: Steven Lang Version: LMDB 0.9.16 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/steven-lang-150929.c Submission from: (NULL) (199.255.44.5) While doing some testing using randomized key and data lengths and random puts and deletes, I found a situation in which mdb_cursor_del(...) followed by mdb_cursor_get(..., MDB_NEXT) causes an error: mdb.c:5726: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() Aborted After a little debugging I was able to isolate what the cause was and produce a simple program to reproduce the issue; during the re-balance following a delete, it would try to move a node from the first child of the root page to the second. If the node it moves has a key longer than the second node in the root page, and the new key doesn't fit, it will split the root page. As a result, by deleting a node, the tree becomes deeper. However, the cursor only checks and compensates for the tree becoming shallower. So now the cursor was pointing to a branch page rather than a leaf page. Any further cursor operations fail. (Trying to do a MDB_SET, MDB_SET_RANGE, etc will silently fail at this point, while MDB_NEXT and possibly MDB_PREV will assert.) The latest head with the fix for ITS#8221 changes the behavior slightly, due to the different arrangement of the tree with the less aggressive merging. However, it still fails. Attached is a program which fills a DB, then deletes keys until it asserts.

1 0

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: Fixed on mdb.RE/0.9. Closing this ITS, use #8221. > >>>>>> 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

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> </div></div><div class=3D"gmail_extra"> <div class=3D"gmail_= quote">On Fri, Sep 25, 2015 at 11:02 AM, <<a href=3D"= mailto:openldap-its@openldap.org" target=3D"_blank">openldap-its(a)openldap.o= rg</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > 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.=C2=A0 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.=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) in the subject will automatically be attached to the issue report. =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) You may follow the progress of this report by loading the following URL in a web browser: =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> Please remember to retain your issue tracking number (ITS#8256) on any further messages you send to us regarding this report.=C2=A0 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. =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> -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. </blockquote></div> </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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs