openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8066) mdb_load truncates long values when resizing buffer
by catwell＠archlinux.us 26 Feb '15

26 Feb '15

For what it's worth, here is a slightly better patch. The previous one would start the strlen() one character too far. I don't think it would have much consequence in practice, but this should be safer. --- libraries/liblmdb/mdb_load.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/libraries/liblmdb/mdb_load.c b/libraries/liblmdb/mdb_load.c index f626692..960d23d 100644 --- a/libraries/liblmdb/mdb_load.c +++ b/libraries/liblmdb/mdb_load.c @@ -216,9 +216,8 @@ badend: prog, lineno); return EOF; } - c1 = buf->mv_data; - c1 += buf->mv_size; - if (fgets((char *)c1, buf->mv_size, stdin) == NULL) { + c1 = buf->mv_data + buf->mv_size - 1; + if (fgets((char *)c1, buf->mv_size+1, stdin) == NULL) { Eof = 1; badend(); return EOF; -- Pierre Chapuis

1 0

(ITS#8066) mdb_load truncates long values when resizing buffer
by catwell＠archlinux.us 26 Feb '15

26 Feb '15

Full_Name: Pierre Chapuis Version: master OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.238.40.212) Description: Starting from 2048, the first input line larger than any power of two N is truncated to N-1. This results in truncated values in the database. Explanation: In the code that resizes the input buffer, fgets() is used. fgets(*, n, *) reads a maximum of n-1 characters and 0-terminates the string. When the next chunk is read, the '\0' remains in the string. Later, strlen() is used and the string is truncated. Proposed fix: A patch against the current OpenLDAP master llllows. --- libraries/liblmdb/mdb_load.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libraries/liblmdb/mdb_load.c b/libraries/liblmdb/mdb_load.c index f626692..e86b6fd 100644 --- a/libraries/liblmdb/mdb_load.c +++ b/libraries/liblmdb/mdb_load.c @@ -218,7 +218,7 @@ badend: } c1 = buf->mv_data; c1 += buf->mv_size; - if (fgets((char *)c1, buf->mv_size, stdin) == NULL) {D%D + if (fgets((char *)c1-1, buf->mv_size+1, stdin) == NULL) { Eof = 1; badend(); return EOF; ---

1 0

Re: (ITS#8064) SIGSEGV in monitor-shutdown code
by leo＠yuriev.ru 25 Feb '15

25 Feb '15

Yes, Howard you are right. In our CI-process 'make test' crashes only for 2.5 branch. I was noted 2.4 in the ITS, it's my mistake. To fix this bug seems a de-registration should be provided by monitor-backend. 2015-02-25 17:47 GMT+03:00 Howard Chu <hyc(a)symas.com>: > pierangelo.masarati(a)polimi.it wrote: >> >> back-monitor was designed before back-config, without considering the >> possibility of database removal during regular operations. There might >> be several flaws of that kind. > > > Removal is not supported in 2.4. All of that is work-in-progress for 2.5. > Patches welcome, but this is not a 2.4 bug. > > >> My suggestion is that back-monitor is never shut down (it should be >> inhibited) except at slapd shutdown. Meanwhile, the code initialization >> and shutdown could be redesigned to properly handle those cases. >> >> On 25/02/2015 15:18, leo(a)yuriev.ru wrote: >>> >>> Full_Name: Leonid Yuriev >>> Version: 2.4-HEAD >>> OS: RHEL7 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (31.130.36.33) >>> >>> >>> Monitor-backend shutdown code could call a callback from registered >>> subsystem >>> after it is already destroyed. >>> >>> For instance, currently ldap-backend frees its own registered context >>> (lmi_mss >>> from ldap_monitor_info_t) before than monitor_back_db_destroy() will be >>> called. >>> >>> Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend >>> database is configured and such freed context will be overwrited. >>> >>> This bug could be reproduced by a filling-memory-with-non-zero before >>> calling >>> free() from glibc. >>> >>> >>> >> >> > > > -- > -- 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#8065) autogroup+accesslog problems
by hyc＠openldap.org 25 Feb '15

25 Feb '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (199.188.194.66) Submitted by: hyc The autogroup overlay doesn't work well with accesslog. This is the same problem we've had in the past with e.g. memberof, refint, and other overlays that do internal modifications as a side-effect of a main user operation. In particular, autogroup's internal ops use the same timestamp as the original op, so accesslog will log one of these internal ops and then none of the others because it uses the timestamp for the RDN of its log entries, and that RDN is already in use. This means the main user onevever gets logged, nor do any side-effect modifications after the first one. The solution in previous cases has been to turn off all accesslog activity for internal operations. In the case of accesslog used for replication, accesslog shoulononly log the main user operation, and it's up to replicas to perform the same internal operations themselves as needed.

1 0

Re: (ITS#8064) SIGSEGV in monitor-shutdown code
by hyc＠symas.com 25 Feb '15

25 Feb '15

pierangelo.masarati(a)polimi.it wrote: > back-monitor was designed before back-config, without considering the > possibility of database removal during regular operations. There might > be several flaws of that kind. Removal is not supported in 2.4. All of that is work-in-progress for 2.5. Patches welcome, but this is not a 2.4 bug. > My suggestion is that back-monitor is never shut down (it should be > inhibited) except at slapd shutdown. Meanwhile, the code initialization > and shutdown could be redesigned to properly handle those cases. > > On 25/02/2015 15:18, leo(a)yuriev.ru wrote: >> Full_Name: Leonid Yuriev >> Version: 2.4-HEAD >> OS: RHEL7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (31.130.36.33) >> >> >> Monitor-backend shutdown code could call a callback from registered subsystem >> after it is already destroyed. >> >> For instance, currently ldap-backend frees its own registered context (lmi_mss >> from ldap_monitor_info_t) before than monitor_back_db_destroy() will be called. >> >> Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend >> database is configured and such freed context will be overwrited. >> >> This bug could be reproduced by a filling-memory-with-non-zero before calling >> free() from glibc. >> >> >> > > -- -- 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#8064) SIGSEGV in monitor-shutdown code
by pierangelo.masarati＠polimi.it 25 Feb '15

25 Feb '15

back-monitor was designed before back-config, without considering the possibility of database removal during regular operations. There might be several flaws of that kind. My suggestion is that back-monitor is never shut down (it should be inhibited) except at slapd shutdown. Meanwhile, the code initialization and shutdown could be redesigned to properly handle those cases. On 25/02/2015 15:18, leo(a)yuriev.ru wrote: > Full_Name: Leonid Yuriev > Version: 2.4-HEAD > OS: RHEL7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (31.130.36.33) > > > Monitor-backend shutdown code could call a callback from registered subsystem > after it is already destroyed. > > For instance, currently ldap-backend frees its own registered context (lmi_mss > from ldap_monitor_info_t) before than monitor_back_db_destroy() will be called. > > Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend > database is configured and such freed context will be overwrited. > > This bug could be reproduced by a filling-memory-with-non-zero before calling > free() from glibc. > > > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#8064) SIGSEGV in monitor-shutdown code
by leo＠yuriev.ru 25 Feb '15

25 Feb '15

Full_Name: Leonid Yuriev Version: 2.4-HEAD OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) Monitor-backend shutdown code could call a callback from registered subsystem after it is already destroyed. For instance, currently ldap-backend frees its own registered context (lmi_mss from ldap_monitor_info_t) before than monitor_back_db_destroy() will be called. Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend database is configured and such freed context will be overwrited. This bug could be reproduced by a filling-memory-with-non-zero before calling free() from glibc.

1 0

(ITS#8063) syncprov+autogroup deadlock
by hyc＠openldap.org 25 Feb '15

25 Feb '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (199.188.194.66) Submitted by: hyc syncprov can deadlock itself if a persistent search is active while a group entry controlled by autogroup is being modified. Fix coming shortly.

1 0

Re: (ITS#8062) Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
by g＠wenarab.com 24 Feb '15

24 Feb '15

--bcaec53d526febcac5050fd27aa4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Thanks for the report. Unfortunately, it appears the DB was constructed > incorrectly at some time in the past, so even updating to later revisions > of the code won't avoid the crash. It's more important now to find the > sequence of steps that recreates the invalid DB in the first place, or > verify that the same sequence doesn't crash using the 0.9.15 release > candidate. OK. I'll try to reproduce the steps. Thanks. G *=E2=80=94 http://gawen.me/ <http://gawen.me/> **- +33 (0) 6 65 42 31 83* On Tue, Feb 24, 2015 at 1:49 AM, Howard Chu <hyc(a)symas.com> wrote: > g(a)wenarab.com wrote: > >> Full_Name: Gawen Arab >> Version: 0.9.14 >> OS: OSX >> URL: http://gawen.me/pub/lmdb_crash/gawen-150223.tar.xz >> Submission from: (NULL) (77.151.59.7) >> >> >> Hello, >> >> I'm currently developing a virtual filesystem whose metadata are stored >> in a >> LMDB 0.9.14 database. This software can currently run over Android, iOS, >> Linux, >> OSX and Windows. >> >> This software is currently used by 50 users and I received 11 crash >> reports of >> SIGSEV raised in LMDB. All reports come from OSX computers. >> > > Thanks for the report. Unfortunately, it appears the DB was constructed > incorrectly at some time in the past, so even updating to later revisions > of the code won't avoid the crash. It's more important now to find the > sequence of steps that recreates the invalid DB in the first place, or > verify that the same sequence doesn't crash using the 0.9.15 release > candidate. > > >> mdb.c:5382: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() >> >> This comes from this assertion >> https://gitorious.org/mdb/mdb/source/2f587ae081d076e3707360c5db0865 >> 20c219d3ea:libraries/liblmdb/mdb.c#L5382 >> . >> >> This happens when the software iterates over keys in the database, the >> same way >> mdb_dump does, calling in loop mdb_cursor_get(..., MDB_NEXT). >> >> I managed to get back the LMDB db folder from one user which runs on OSX >> 64bits. >> I performed a mdb_dump of it with my Linux 64bits. mdb_dump crashes the >> same >> way. I tried with the lastest mdb_dump from the mdb.master branch (commi= t >> 3368d1f5e243225cba4d730fba19ff600798ebe3), but I have the same assertion= . >> >> mdb.c:5599: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() >> >> I attached to this issue the faulty database 'db/'. >> >> The output of mdb_dump on my machine is attached to this issue named as >> the >> file >> 'mdb_dump.log'. I runned back mdb_dump with MDB_DEBUG defined to 2 and >> mdb_debug >> true. I attached the output of this new dump as the file >> 'mdb_dump.debug.log'. >> The interesting part: >> >> mdb_cursor_next:5574 cursor_next: top page is 1946 in cursor 0x1897350 >> mdb_cursor_next:5591 =3D=3D> cursor points to page 1946 with 50 keys, ke= y >> index 48 >> b5f1ff0700000000 >> 0700000000000000bc10000000000000000e000000000000860d00000000 >> 0000e308000000000000ee07000000000000a5070000000000000307000000000000 >> mdb_cursor_next:5574 cursor_next: top page is 1946 in cursor 0x1897350 >> mdb_cursor_next:5591 =3D=3D> cursor points to page 1946 with 50 keys, ke= y >> index 49 >> b6f1ff0700000000 >> 0700000000000000820e000000000000310e000000000000770d00000000 >> 0000660c000000000000cb0a0000000000002a080000000000000008000000000000 >> mdb_cursor_next:5574 cursor_next: top page is 1946 in cursor 0x1897350 >> mdb_cursor_next:5579 =3D=3D=3D=3D=3D> move to next sibling page mdb_curs= or_pop:5095 >> popped >> page 1946 off db 1 cursor 0x1897350 mdb_cursor_sibling:5503 parent page >> is page >> 4643, index 16 mdb_cursor_sibling:5521 just moving to right index key 17 >> mdb_cursor_push:5104 pushing page 704 on db 1 cursor 0x1897350 >> mdb_cursor_next:5585 next page is 704, key index 0 mdb_cursor_next:5591 >> =3D=3D> >> cursor points to page 704 with 7 keys, key index 0 mdb.c:5599: Assertion >> 'IS_LEAF(mp)' failed in mdb_cursor_next() >> %%0 >> I do not know much about internal LMDB design for now, so I'm struggling >> to >> understand the debug lines... >> >> Unfortunately, I do not know how to reproduce this bug, but it is a >> recurring >> one. >> >> Maybe the following information can help you, >> >> - My software opens the database in MDB_NOSYNC mode, and performs a >> mdb_env_sync(env, 1) every second or less. A mdb_env_sync can happen >> at the >> same time of any other operation (i.e. mdb_txn_commit). I didn't put >> any lock >> mechanism. Could this expln n such situation ? >> >> - mapsize is currently 512MiB. Previous versions of the software set to >> smaller >> values (the database had not been rebuilt since). >> >> I'd be happy to provide more information if you need. >> >> Thank you for your support and this amazing IP. >> >> Regards >> >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --bcaec53d526febcac5050fd27aa4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l= eft-style:solid;padding-left:1ex">Thanks for the report. Unfortunately, it appears the DB was constructed= incorrectly at some time in the past, so even updating to later revisions = of the code won't avoid the crash. It's more important now to find = the sequence of steps that recreates the invalid DB in the first place, or = verify that the same sequence doesn't crash using the 0.9.15 release ca= ndidate.</blockquote><div> </div><div>OK. I'll try to reprodu= ce the steps.</div><div> </div><div>Thanks.</div></div><div class=3D"gma= il_extra"> <div><div class=3D"gmail_signature"><div dir=3D= "ltr"><div><div><div><div><div>G</spa= n> <sp= an style=3D"font-weight:normal">=E2=80=94=C2=A0 </= span><spa= n style=3D"color:rgb(68,68,68)"><a href=3D"http://gawen.me/" target=3D"_bla= nk">http://gawen.me/</a> - +33 (0) 6 65 42 31 83</= span></div></sp= an><div><= span style=3D"border-collapse:collapse"></div></div></div></d= iv></div> </div></div></div> <div class=3D"gmail_quote">On Tue, Feb 24, 2015 at 1:49 AM, Howard Chu = <<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hy= c(a)symas.com</a>> wrote: <blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href= =3D"mailto:g@wenarab.com" target=3D"_blank">g(a)wenarab.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Gawen Arab Version: 0.9.14 OS: OSX URL: <a href=3D"http://gawen.me/pub/lmdb_crash/gawen-150223.tar.xz" target= =3D"_blank">http://gawen.me/pub/lmdb_crash/gawen-150223.tar.xz</a><b= r> Submission from: (NULL) (77.151.59.7) Hello, I'm currently developing a virtual filesystem whose metadata are stored= in a LMDB 0.9.14 database. This software can currently run over Android, iOS, Li= nux, OSX and Windows. This software is currently used by 50 users and I received 11 crash reports= of SIGSEV raised in LMDB. All reports come from OSX computers. </blockquote> Thanks for the report. Unfortunately, it appears the DB was constructed inc= orrectly at some time in the past, so even updating to later revisions of t= he code won't avoid the crash. It's more important now to find the = sequence of steps that recreates the invalid DB in the first place, or veri= fy that the same sequence doesn't crash using the 0.9.15 release candid= ate. <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> mdb.c:5382: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() This comes from this assertion <a href=3D"https://gitorious.org/mdb/mdb/source/2f587ae081d076e3707360c5db0= 86520c219d3ea:libraries/liblmdb/mdb.c#L5382" target=3D"_blank">https://gito= rious.org/mdb/mdb/source/2f587ae081d076e3707360c5db0865</u= >20c219d3ea:libraries/liblmdb/mdb.c#L5382</a> . This happens when the software iterates over keys in the database, the same= way mdb_dump does, calling in loop mdb_cursor_get(..., MDB_NEXT). I managed to get back the LMDB db folder from one user which runs on OSX<br= > 64bits. I performed a mdb_dump of it with my Linux 64bits. mdb_dump crashes the sam= e way. I tried with the lastest mdb_dump from the mdb.master branch (commit<b= r> 3368d1f5e243225cba4d730fba19ff600798ebe3), but I have the same asser= tion. mdb.c:5599: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() I attached to this issue the faulty database 'db/'. The output of mdb_dump on my machine is attached to this issue named as the= file 'mdb_dump.log'. I runned back mdb_dump with MDB_DEBUG defined to 2 = and mdb_debug true. I attached the output of this new dump as the file 'mdb_dump.debu= g.log'. The interesting part: mdb_cursor_next:5574 cursor_next: top page is 1946 in cursor 0x1897350 mdb_cursor_next:5591 =3D=3D> cursor points to page 1946 with 50 keys, ke= y index 48 b5f1ff0700000000 0700000000000000bc10000000000000000e000000000000860d000000000= 000e308000000000000ee07000000000000a5070000000000000307000000= 000000 mdb_cursor_next:5574 cursor_next: top page is 1946 in cursor 0x1897350 mdb_cursor_next:5591 =3D=3D> cursor points to page 1946 with 50 keys, ke= y index 49 b6f1ff0700000000 0700000000000000820e000000000000310e000000000000770d000000000= 000660c000000000000cb0a0000000000002a080000000000000008000000= 000000 mdb_cursor_next:5574 cursor_next: top page is 1946 in cursor 0x1897350 mdb_cursor_next:5579 =3D=3D=3D=3D=3D> move to next sibling page mdb_curs= or_pop:5095 popped page 1946 off db 1 cursor 0x1897350 mdb_cursor_sibling:5503 parent page is = page 4643, index 16 mdb_cursor_sibling:5521 just moving to right index key 17<br= > mdb_cursor_push:5104 pushing page 704 on db 1 cursor 0x1897350 mdb_cursor_next:5585 next page is 704, key index 0 mdb_cursor_next:5591 =3D= =3D> cursor points to page 704 with 7 keys, key index 0 mdb.c:5599: Assertion<br= > 'IS_LEAF(mp)' failed in mdb_cursor_next() %%0 I do not know much about internal LMDB design for now, so I'm strugglin= g to understand the debug lines... Unfortunately, I do not know how to reproduce this bug, but it is a recurri= ng one. Maybe the following information can help you, - My software opens the database in MDB_NOSYNC mode, and performs a =C2=A0 =C2=A0mdb_env_sync(env, 1) every second or less. A mdb_env_sync can = happen at the =C2=A0 =C2=A0same time of any other operation (i.e. mdb_txn_commit). I didn= 't put any lock =C2=A0 =C2=A0mechanism. Could this expln n such situation ? - mapsize is currently 512MiB. Previous versions of the software set to sma= ller =C2=A0 =C2=A0values (the database had not been rebuilt since). I'd be happy to provide more information if you need. Thank you for your support and this amazing IP. Regards </blockquote> -- =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> </div> --bcaec53d526febcac5050fd27aa4--

1 0

Re: (ITS#8054) Operation duration logging
by clem.oudot＠gmail.com 24 Feb '15

24 Feb '15

2015-02-11 18:33 GMT+01:00 <h.b.furuseth(a)usit.uio.no>: > On 11. feb. 2015 12:38, Michael Str=C3=B6der wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Cool feture, but please use fewer characteres in the already >>> bloated log. How about "time=3D<integer>us" or even omit the "us"? >> >> +1 >> >> But 'time' sounds a bit general. >> How about 'tdu' or even 'td' as abbreviation for "time duration"? > > I don't think so. You can't see from that what it means unless you > already know, so you have to look it up just to see if you're > interested. 'time' you can decide to look up if you are interested. > Seems other LDAP servers have choosen 'etime' (see http://ludopoitou.com/2015/02/24/about-auditing-ldap-operations/). Why not try to use the same word? Cl=C3=A9ment OUDOT.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs