openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

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

30 Jun '15

On 29/06/15 23:05, hyc(a)symas.com wrote: > Seriously, why aren't we just saying "don't do this" and moving on? OK, then document it. Maybe keeping it simple, call mixing mainDB data and named DBs a user error and warn this can break the DB. > There are > lots of stupid things you can do with software. It's a waste of time and > energy to prevent them all. We totally disagree, starting with what is stupid. But we knew that. That's I asked which parts of "mdb/bundle" to push and which you rejected, we must have misunderstood each other. I thought I was just ITSing this commit properly before pushing.

1 0

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

30 Jun '15

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Can I raise the debug level? Log level trace does not really show the ori= >> ginal >> byte sequence received by the external listener. > > Currently there is no debug code for this. Actually, if you use debug level SHELL you'll get a plaintext dump of the received text. If you direct this into a file you can examine it with a hex editor. -- -- 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 hyc＠symas.com 30 Jun '15

30 Jun '15

michael(a)stroeder.com wrote: > 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. Sure it does: print "dn: cn=test, dc=example, dc=com\n"; print "cn: test\n"; print "objectclass: cnobject\n"; print "\n"; print "RESULT\n"; print "code: 0\n"; print "info: answered by process $$\n"; And the result at the client: violino:~/OD/hobj/tests> ../clients/tools/ldapsearch -x -H ldap://:9011 -b dc=example,dc=com # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # test, example.com dn: cn=test,dc=example,dc=com cn: test objectClass: cnobject # search result search: 2 result: 0 Success text: answered by process 3077 # numResponses: 2 # numEntries: 1 Notice there are no embedded NUL characters. Only newlines. > 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. Currently there is no debug code for this. At any rate, the code uses fgets(3) which stops reading at a newline character. The fact that your string isn't being parsed correctly implies either libc fgets is broken inside your slapd process (pretty unlikely) or your socket sender isn't really sending newline characters. -- -- 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#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

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