openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8516) TAG decoding incorrect when longer than 1 byte
by elecharny＠gmail.com 12 Oct '16

12 Oct '16

Le 11/10/16 à 19:56, Hallvard Breien Furuseth a écrit : > On 11. okt. 2016 18:10, elecharny(a)apache.org wrote: >> IMO, the code that deal with tags in the lber decode.c >> ber_tag_and_rest() method >> is incorrectly decoding tags that are longer than 1 byte. (...) > > It's far too late to change the ASN.1 <-> integer mapping. liblber is > widely used outside OpenLDAP, we don't know if we'd break something. I think I overlooked the origial code. See later... > > As lber.h explains: > * ber_tag_t represents the identifier octets at the beginning of BER > * elements. OpenLDAP treats them as mere big-endian unsigned integers. Indeed. That means the method just grabs bytes without taking care of the 'continuation' bits (ie the 7th bit if there are more bytes after), and returns a long. > > I wish it had at least used little-endian so we could check the class > and P/C bits with a simple '&' operation. Oh well. Well, the way this function works make it hard to do so, I agree. OTOH, it means this ITS can be closed, because it's based on a wrong understanding on what this method does. It's not bugy, it's just doing somethig different than what I was expecting. Thanks !

1 0

Re: (ITS#8516) TAG decoding incorrect when longer than 1 byte
by h.b.furuseth＠usit.uio.no 11 Oct '16

11 Oct '16

On 11. okt. 2016 18:10, elecharny(a)apache.org wrote: > IMO, the code that deal with tags in the lber decode.c ber_tag_and_rest() method > is incorrectly decoding tags that are longer than 1 byte. (...) It's far too late to change the ASN.1 <-> integer mapping. liblber is widely used outside OpenLDAP, we don't know if we'd break something. As lber.h explains: * ber_tag_t represents the identifier octets at the beginning of BER * elements. OpenLDAP treats them as mere big-endian unsigned integers. I wish it had at least used little-endian so we could check the class and P/C bits with a simple '&' operation. Oh well. -- Hallvard

1 0

(ITS#8516) TAG decoding incorrect when longer than 1 byte
by elecharny＠apache.org 11 Oct '16

11 Oct '16

Full_Name: Emmanuel Lecjarny Version: 2.4.44 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.92.161.247) IMO, the code that deal with tags in the lber decode.c ber_tag_and_rest() method is incorrectly decoding tags that are longer than 1 byte. Not that it is a huge problem for OpenLDAP, because we always use 1 byte long tags, but from the ASN.1 BER decoding POV, that wilbrbreak when having a 2 bytes long tag : 116 do { 117 if ( rest <= 0 ) { 118 break; 119 } 120 tag <<= 8; 121 tag |= *ptr++ & 0xffU; 122 rest--; 123 124 if ( ! (tag & LBER_MORE_TAG_MASK) ) { 125 goto done; 126 } 127 } while ( tag <= (ber_tag_t)-1 / 256 ); should read 114 tag = (ber_tag_t) 0x00U; 115 116 do { 117 if ( rest <= 0 ) { 118 break; 119 } 120 tag <<= 7; 121 tag |= *ptr++ & 0x7fU; 122 rest--; 123 124 if ( ! (tag & LBER_MORE_TAG_MASK) ) { 125 goto done; 126 } 127 } while ( tag <= (ber_tag_t)-1 / 256 ); The reason being that BER encoding for Tags when longer than 1 byte looks like : [class|P/C|11111] - [1|uuu uuuu] - [1|uuu uuuu] - [1|uuu uuuu] - ... - [0|uuu uuuu] byte 1 byte 2 byte 3 byte 4 byte N and the 'uuu uuuu' parts are only 7 bits long.

1 0

Re: (ITS#8515) => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792)
by michael＠stroeder.com 10 Oct '16

10 Oct '16

sebastiaan.van.zanten(a)ing.nl wrote: > Version: 2.4.4 ^^^^^ Sure? > However we installed it as an MDB database > and now we receive the following error: > > => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize > limit reached (-30792) > > Apparently the settings were default and it exceeded the size of 10mb. We have > plenty of diskspace on the machine. However we are unsure how to update this. > Can you advise us how we do this? In general usage questions should not be added as ticket. Please use the openldap-technical mailing list instead. In your case you can increase the DB size with the slapd.conf directive "maxsize" (or the equivalent attribute when using cn=config) and restart slapd. Ciao, Michael.

1 0

(ITS#8515) => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792)
by sebastiaan.van.zanten＠ing.nl 10 Oct '16

10 Oct '16

Full_Name: Sebastiaan van Zanten Version: 2.4.4 OS: Redhat 6.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.221.52.104) Dear Sir/Madam, We are using openldap as an overlay between our corporate ldap and some other tooling (gitlab, artifactory, etc). However we installed it as an MDB database and now we receive the following error: => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792) Apparently the settings were default and it exceeded the size of 10mb. We have plenty of diskspace on the machine. However we are unsure how to update this. Can you advise us how we do this? Kind Regards, Sebastiaan van Zanten

1 0

(ITS#8514) segfault for large entries
by steffen.hofmann＠fu-berlin.de 09 Oct '16

09 Oct '16

Full_Name: Steffen Hofmann Version: 2.4.44 OS: Debian 3.16.36-1+deb8u1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.65.185.225) When searching large entries (e.g. >65kb) slapd segfaults. from log: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" from strace: 816254 write(9, "<deleted content>"..., 105957) = 67160 816254 write(9, "<deleted content>"..., 38797) = -1 EAGAIN (Resource temporarily unavailable) 816254 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7efd4f9438d0} --- from coredump: #0 0x00002aaec12318d0 in ?? () #1 0x000000000044d2d7 in slap_writewait_play (op=0x2aafb41041b0) at result.c:294 #2 send_ldap_ber (op=op@entry=0x2aafb41041b0, ber=ber@entry=0x2aafaeca3000) at result.c:367 #3 0x0000000000450550 in slap_send_search_entry (op=0x2aafb41041b0, rs=0x2aafaee34a70) at result.c:1430 #4 0x00000000004d135b in mdb_search (op=<oimimized out>, rs=0x2aafaee34a70) at search.c:1086 #5 0x00000000004a2f4d in overlay_op_walk (op=0x2aafb41041b0, rs=0x2aafaee34a70, which=op_search, oi=0x1907760, on=0x0) at backover.c:677 #6 0x00000000005a83e2 in slapi_op_func (op=0x2aafb41041b0, rs=0x2aafaee334c0) at slapi_overlay.c:650 #7 0x00000000004a2f0a in overlay_op_walk (op=op@entry=0x2aafb41041b0, rs=0x2aafaee34a70, which=op_search, oi=0x1907760, on=0x1907940) at backover.c:661 #8 0x00000000004a3087 in over_op_func (op=0x2aafb41041b0, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #9 0x00000000004a31aa in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #10 0x00000000004414aa in fe_op_search (op=0x2aafb41041b0, rs=0x2aafaee34a70) at search.c:402 #11 0x00000000004a2f4d in overlay_op_walk (op=op@entry=0x2aafb41041b0, rs=0x2aafaee34a70, which=op_search, oi=0x18a1430, on=0x0) at backover.c:677 #12 0x00000000004a3087 in over_op_func (op=0x2aafb41041b0, rs=<optimized out>C C which=which@entry=op_search) at backover.c:730 #13 0x00000000004a31aa in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #14 0x000000000044100c in do_search (op=0x2aafb41041b0, rs=0x2aafaee34a70) at search.c:247 #15 0x000000000043eca6 in connection_operation (ctx=ctx@entry=0x2aafaee34b90, arg_v=arg_v@entry=0x2aafb41041b0) at connection.c:1158 #16 0x000000000043fa4b in connection_read_thread (ctx=0x2aafaee34b90, argv=0x9) at connection.c:1294 #17 0x0000000000570293 in ldap_int_thread_pool_wrapper (xpool=0x184bd30) at tpool.c:696 #18 0x00002aaebcc360a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #19 0x00002aaebcf3362d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) up #1 0x000000000044d2d7 in slap_writewait_play (op=0x2aafb41041b0) at result.c:294 294 sc->sc_writewait( op, sc ); (gdb) list 289 { 290 slap_callback *sc = op->o_callback; 291 292 for ( ; sc; sc = sc->sc_next ) { 293 if ( sc->sc_writewait ) 294 sc->sc_writewait( op, sc ); 295 } 296 } 297 298 static long send_ldap_ber( I think, the change that cause the error was made with the new function slap_writewait_play in the version 2.4.40 in servers/slapd/result.c I hope it is helpful. Steffen

1 0

(ITS#8513) Updates to TOTP README
by okuznik＠symas.com 09 Oct '16

09 Oct '16

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20161009-TOTP-README-updates.… Submission from: (NULL) (151.227.182.144) Some notes in the TOTP module's README file are inaccurate. The linked patch corrects those.

1 0

(ITS#8512) segfault for large entries
by steffen.hofmann＠fu-berlin.de 07 Oct '16

07 Oct '16

Full_Name: Steffen Hofmann Version: 2.4.44 OS: Debian 3.16.36-1+deb8u1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.77.77.78) When searching large entries (e.g. >65kb) slapd segfaults. from log: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" from strace: 816254 write(9, "<deleted content>"..., 105957) = 67160 816254 write(9, "<deleted content>"..., 38797) = -1 EAGAIN (Resource temporarily unavailable) 816254 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7efd4f9438d0} --- from coredump: #0 0x00002aaec12318d0 in ?? () #1 0x000000000044d2d7 in slap_writewait_play (op=0x2aafb41041b0) at result.c:294 #2 send_ldap_ber (op=op@entry=0x2aafb41041b0, ber=ber@entry=0x2aafaeca3000) at result.c:367 #3 0x0000000000450550 in slap_send_search_entry (op=0x2aafb41041b0, rs=0x2aafaee34a70) at result.c:1430 #4 0x00000000004d135b in mdb_search (op=<oimimized out>, rs=0x2aafaee34a70) at search.c:1086 #5 0x00000000004a2f4d in overlay_op_walk (op=0x2aafb41041b0, rs=0x2aafaee34a70, which=op_search, oi=0x1907760, on=0x0) at backover.c:677 #6 0x00000000005a83e2 in slapi_op_func (op=0x2aafb41041b0, rs=0x2aafaee334c0) at slapi_overlay.c:650 #7 0x00000000004a2f0a in overlay_op_walk (op=op@entry=0x2aafb41041b0, rs=0x2aafaee34a70, which=op_search, oi=0x1907760, on=0x1907940) at backover.c:661 #8 0x00000000004a3087 in over_op_func (op=0x2aafb41041b0, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #9 0x00000000004a31aa in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #10 0x00000000004414aa in fe_op_search (op=0x2aafb41041b0, rs=0x2aafaee34a70) at search.c:402 #11 0x00000000004a2f4d in overlay_op_walk (op=op@entry=0x2aafb41041b0, rs=0x2aafaee34a70, which=op_search, oi=0x18a1430, on=0x0) at backover.c:677 #12 0x00000000004a3087 in over_op_func (op=0x2aafb41041b0, rs=<optimized out>C C which=which@entry=op_search) at backover.c:730 #13 0x00000000004a31aa in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #14 0x000000000044100c in do_search (op=0x2aafb41041b0, rs=0x2aafaee34a70) at search.c:247 #15 0x000000000043eca6 in connection_operation (ctx=ctx@entry=0x2aafaee34b90, arg_v=arg_v@entry=0x2aafb41041b0) at connection.c:1158 #16 0x000000000043fa4b in connection_read_thread (ctx=0x2aafaee34b90, argv=0x9) at connection.c:1294 #17 0x0000000000570293 in ldap_int_thread_pool_wrapper (xpool=0x184bd30) at tpool.c:696 #18 0x00002aaebcc360a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #19 0x00002aaebcf3362d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) up #1 0x000000000044d2d7 in slap_writewait_play (op=0x2aafb41041b0) at result.c:294 294 sc->sc_writewait( op, sc ); (gdb) list 289 { 290 slap_callback *sc = op->o_callback; 291 292 for ( ; sc; sc = sc->sc_next ) { 293 if ( sc->sc_writewait ) 294 sc->sc_writewait( op, sc ); 295 } 296 } 297 298 static long send_ldap_ber( I think, the change that cause the error was made with the new function slap_writewait_play in the version 2.4.40 in servers/slapd/result.c I hope it is helpful. Steffen

1 0

Re: (ITS#8511) Rename "mirrormode" to "multimaster", deprecate "mirrormode" parameter
by michael＠stroeder.com 06 Oct '16

06 Oct '16

quanah(a)openldap.org wrote: > In bconfig.c, the following should be reworked: > [..] > So that the parameter name is multimaster, and the config attr is > olcMultiMaster > > The term "mirrormode" is both confusing and misleading, as what it really > controls is whether or not this node is enabled for multimaster. +1 Ciao, Michael.

1 0

(ITS#8511) Rename "mirrormode" to "multimaster", deprecate "mirrormode" parameter
by quanah＠openldap.org 06 Oct '16

06 Oct '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) In bconfig.c, the following should be reworked: { "mirrormode", "on|off", 2, 2, 0, ARG_DB|ARG_ON_OFF|ARG_MAGIC|CFG_MIRRORMODE, &config_generic, "( OLcfgDbAt:0.16 NAME 'olcMirrorMode' " So that the parameter name is multimaster, and the config attr is olcMultiMaster The term "mirrormode" is both confusing and misleading, as what it really controls is whether or not this node is enabled for multimaster.

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