openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

Re: (ITS#8181) LMDB page leaks etc when treating DBs as data
by hyc＠symas.com 29 Jun '15

29 Jun '15

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: LMDB_0.9.15 > OS: > URL: > Submission from: (NULL) (81.191.45.5) > Submitted by: hallvard > > > The user can overwrite or delete a named DB record > with normal data. This leaks the pages of the DB. > Also the new non-DB can then be treated as a DB. > A fix is coming (from my branch mdb/bundle). Seriously, why aren't we just saying "don't do this" and moving on? There are lots of stupid things you can do with software. It's a waste of time and energy to prevent them all. -- -- 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#8048) back-sock/slapo-sock issue
by michael＠stroeder.com 29 Jun '15

29 Jun '15

Howard Chu wrote: > michael(a)stroeder.com wrote: >> michael(a)stroeder.com wrote: >>> Null-bytes really needed? >> >> Hmm, with null-bytes the wrong result code is returned to the LDAP cli= ent. >> >> Without null-bytes the correct result code is returned to the client b= ut slapd >> complains about unknown string: >> >> 'RESULT\nmsgid: 1\ncode: 49\nmatched: uid=3Dwuqww,cn=3Dampua,ou=3Dampu= a\ninfo: >> NOK\n\n' >> >> results in log message: >> >> 559174df str2result (msgid: 1 >> code: 0 >> >> ) unknown >> 559174df str2result ( >> ) unknown >=20 > I would almost suspect you were running on Windows. None of the behavio= r > you're reporting occurs for me using the searchexample.pl script. Your script does not return any real 'RESULT..' responses. I also have less issues when just returning 'CONTINUE\n'. > Sounds like your problem is a python runtime configuration, not a slapd= > bug. Not on Windows and no run-time configuration involved. Look at the raw string representations I've posted. That string goes dire= ctly to SocketServer.BaseRequestHandler.request.sendall(response_str). Can I raise the debug level? Log level trace does not really show the ori= ginal byte sequence received by the external listener. Ciao, Michael.

1 0

(ITS#8181) LMDB page leaks etc when treating DBs as data
by h.b.furuseth＠usit.uio.no 29 Jun '15

29 Jun '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.15 OS: URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard The user can overwrite or delete a named DB record with normal data. This leaks the pages of the DB. Also the new non-DB can then be treated as a DB. A fix is coming (from my branch mdb/bundle).

1 0

Re: (ITS#8048) back-sock/slapo-sock issue
by hyc＠symas.com 29 Jun '15

29 Jun '15

michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> Null-bytes really needed? > > Hmm, with null-bytes the wrong result code is returned to the LDAP client. > > Without null-bytes the correct result code is returned to the client but slapd > complains about unknown string: > > 'RESULT\nmsgid: 1\ncode: 49\nmatched: uid=wuqww,cn=ampua,ou=ampua\ninfo: NOK\n\n' > > results in log message: > > 559174df str2result (msgid: 1 > code: 0 > > ) unknown > 559174df str2result ( > ) unknown I would almost suspect you were running on Windows. None of the behavior you're reporting occurs for me using the searchexample.pl script. Sounds like your problem is a python runtime configuration, not a slapd 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#8048) back-sock/slapo-sock issue
by michael＠stroeder.com 29 Jun '15

29 Jun '15

michael(a)stroeder.com wrote: > Null-bytes really needed? Hmm, with null-bytes the wrong result code is returned to the LDAP client. Without null-bytes the correct result code is returned to the client but slapd complains about unknown string: 'RESULT\nmsgid: 1\ncode: 49\nmatched: uid=wuqww,cn=ampua,ou=ampua\ninfo: NOK\n\n' results in log message: 559174df str2result (msgid: 1 code: 0 ) unknown 559174df str2result ( ) unknown

1 0

Re: (ITS#8048) back-sock/slapo-sock issue
by michael＠stroeder.com 29 Jun '15

29 Jun '15

Michael Str=F6der wrote: > This is my Python response string: >=20 > 'RESULT\nmsgid: 1\ncode: 49\ninfo: remote NOK\n\n' Hmmpf! After adding null-bytes in each line like this 'RESULT\n\x00msgid: 1\n\x00code: 49\n\x00\n\x00' at least this message went away also with RE24: > This leads to slapd debug output: >=20 > 55914b01 str2result (msgid: 1 > code: 49 > info: remote NOK >=20 > ) unknown > 55914b01 str2result ( > ) unknown Null-bytes really needed? str2result() checks for null-bytes in a bunch o= f cases. I really wonder why null-terminated char *s is used. Ciao, Michael.

1 0

Re: (ITS#8048) back-sock/slapo-sock issue
by michael＠stroeder.com 29 Jun '15

29 Jun '15

hyc(a)openldap.org wrote: > Full_Name: Howard Chu > Version: 2.4 > OS:=20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (110.49.207.42) > Submitted by: hyc >=20 > The result parser is checking for CONTINUE in the wrong place. Please re-open this ticket. RE24 (tagged as 2.4.41) made things worse. Is there a chance to get things fixed? I promise to help testing. First CONTINUE\n works in RE24 better than in 2.4.40 which was the cause = of this ITS. But handling RESULT is seriously broken, even more than in 2.4.40. Example: This is my Python response string: 'RESULT\nmsgid: 1\ncode: 49\ninfo: remote NOK\n\n' This leads to slapd debug output: 55914b01 str2result (msgid: 1 code: 49 info: remote NOK ) unknown 55914b01 str2result ( ) unknown Note that the whole string is returned as being unknown. Also with 2.4.40 my client script receives ' remote NOK' as diagnostic message. With RE24 the diagnostic message is complete garbage. So I tried many response string variants regarding number of \n and leavi= ng away space after the colon etc. But not really working. Sometimes slapd hangs, sometimes my client hangs e.g. when sending two subsequent bind requests in one open LDAP connection.

1 0

(ITS#8180) back-sock should not return sucess in case of error
by michael＠stroeder.com 29 Jun '15

29 Jun '15

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (84.181.173.53) back-sock should definitely never return success(0) to the client in case the external listener returned non-parseable message: Example trace log: 55913915 => str2entry: "FOOBAR msgid: 1 code: 49 " 55913915 <= str2entry NULL (parse_line) 55913915 str2entry: entry -1 has no dn 55913915 str2entry(FOOBAR) failed 55913915 sock: fgets failed: Success (0)

1 0

(ITS#8179) LMDB: Feature Request: mdb_env_check_mapsize(env)
by scott＠GameRanger.com 28 Jun '15

28 Jun '15

Full_Name: Scott Kevill Version: LMDB 0.9.14 OS: CentOS 5-7 URL: ftp://ftp.openldap.org/incoming/scott-kevill-150628.patch Submission from: (NULL) (60.224.160.178) mdb_txn_begin / mdb_txn_renew will return MDB_MAP_RESIZED for the current process if another process has changed the mapsize AND the data has grown past the current process mapsize. However, by that point, in a multithreaded environment it may be difficult to wind back to a "safe" point of no active txns in order to call mdb_env_set_mapsize(env, 0) to update the mapsize. Requesting: int mdb_env_check_mapsize(MDB_env *env); to return either MDB_SUCCESS or MDB_MAP_RESIZED. This should be lightweight enough to call frequently enough to decide whether to initiate a "safe" point to enable calling mdb_env_set_mapsize(env, 0). Return MDB_SUCCESS if the MDB has not been opened yet. Scenario: - Process W is a writer - Process R is a reader with multiple reader threads (read-only) - Both processes are running and using a 2GB mapsize MDB - Data is currently 1GB - Ops decide W should increase mapsize to 3GB allowing for more expansion - W calls mdb_env_set_mapsize(env, 3GB) - R's mapsize remains at 2GB%0 D Data grows - R:1 thread begins a moderately long read-only txn - Data grows past 2GB - R:2 thread tries to begin a read-only txn, but fails with MDB_MAP_RESIZED - R:2 thread cannot call mdb_env_set_mapsize(env, 0), because of R:1's txn - A major control flow issue exists now, as R:2 may be deep into work, but can't continue nor back out With mdb_env_check_mapsize(), R could periodically test it and if needed, initiate a "safe" point where none of R's threads have active txns. This could be done long before the data size actually reaches R's original mapsize (ie. when data is ~1GB rather >2GB). - Enforcing synchronisation to a "safe" point might be relatively expensive, so it would be important to know if the mapsize has changed first. ie. Making mdb_env_set_mapsize(env, 0) lightweight for the unchanged mapsize case isn't enough I've attached a sample patch against master (scott-kevill-150628.patch). I've tested it against 0.9.14. The code is trivial and is based on the behaviour of mdb_env_set_mapsize(env, 0). I didn't use git for the patch, so not too difficult to get working. Less than 10 new lines, but for the record, I release it to public domain. Feel free to massage it as needed.

1 0

Re: (ITS#7791) 3-Way delta MMR segfault
by quanah＠zimbra.com 27 Jun '15

27 Jun '15

--On Saturday, June 27, 2015 8:01 AM +0000 frederic.nass(a)univ-lorraine.fr wrote: > ------=_Part_4076294_1166621201.1435388481648 > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: quoted-printable > > Hi,=20 > > We are facing the exact same situation with a 3-way configuration with > open= ldap-2.4.39.2z packaged by Zimbra 8.6 p2.=20 > > Slapd crashes at some point during first replication. We can reproduce > this= on any of the 3 nodes by stopping ldap service, deleting databases > (access= log and mdb) and restarting ldap service.=20 > > Please tell us how we can be helpful.=20 Provide a gdb backtrace. <http://www.openldap.org/faq/data/cache/59.html> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs