openldap-bugs July 2017

openldap-bugs@openldap.org

22 participants
41 discussions

(ITS#8688) Is it possible to control on the failover of backend LDAP?
by meheni.ziani＠gmail.com 07 Jul '17

07 Jul '17

Full_Name: Meheni Version: 2.4.44 OS: CentOs 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (163.116.6.97) Hello, We have implemented two "OpenLDAP mirror directory": ldaps://ldap1 and ldaps://ldap2 (version 2.4.44) and an LDAP proxy with back_ldap + overlay pcache (version 2.4.44). We want to understand two behaviors found on the LDAP proxy: 1 - We dont succeed to control failover switch between 2 backend LDAP by proxy OpenLDAP. The proxy passes too quickly due to a micro-cutter (for example, a one-second cut). We want to know if there is a way that we can better control the switchover too fast. 2 - We found that when the proxy goes to the second URI (ldaps: // ldap2) (because of a network break of a few seconds), the open connections on the first directory do not close. Besides, when LDAP1 is back, the new requests with the old connection will be arrive to LDAP1 but it should be arrive to LDAP2. Therere only new requests with new connection arriving at LDAP2. Is there a way to close open connections in LDAP1 when the proxy switches to the LDAP2? kind regards, Meheni

1 0

Re: (ITS#8685) Invalid memory access
by hyc＠symas.com 07 Jul '17

07 Jul '17

Breno Leitao wrote: > Hello Howard, > > On Thu, Jul 06, 2017 at 08:55:01PM +0100, Howard Chu wrote: >> leitao(a)debian.org wrote: >>> Full_Name: Breno Leitao >>> Version: upstream >>> OS: Debian >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (32.104.18.202) >>> >>> >>> Currently, do_random() function in tests/progs/slapd-mtread.c uses a random >>> number (upto RAND_MAX) to access an array that is much smaller than RAND_MAX, >>> causing a segfault. >>> >>> This causes a segmentation fault and more details could be found at >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866122 >>> >>> >> Thanks for the report. I've examined your proposed patch in your debian >> bugtracker. It doesn't make much sense though. >> >> The random number is being correctly scaled, line 682: >> >> int r = ((double)nvalues)*rand()/(RAND_MAX + 1.0); >> >> Which means the value of r can only be from 0 to nvalues-1. >> >> And there should be no difference between nvalues and i, since on line 657: >> >> nvalues = ldap_count_entries( ld, res ); >> >> Since i is simply iterated through all of the entries in the response, the >> two values cannot disagree. > > Thanks for looking at it, and your suggestion made me revisit it. let me > share I am finding in the debug. This is the failure frame: You cannot possibly diagnose this with an optimized binary. You're missing several crucial variables. Your analysis here is completely invalid. > > #5 do_read (ld=0x3fff980008e0, entry=0x6e6d756c413d756f <error: Cannot access memory at address 0x6e6d756c413d756f>, > attrs=0x20020058 <srchattrs>, noattrs=<optimized out>, maxloop=<optimized out>, maxretries=<optimized out>, force=<optimized out>, > idx=<optimized out>, chaserefs=<optimized out>, delay=<optimized out>, nobind=<optimized out>) at ../../../../tests/progs/slapd-mtread.c:791 > > On this frame, these are the values we have: > > i = 0 > do_retry = 0 > rc = <optimized out> > thrstr = "Read(1): entry=\"0 cnt: 1 (retried 0) (dc=example,dc=com)\000u=Alumni Association,ou=People,dc=example,dc=com)\000mple,dc=com)", '\000' <repeats 6641 times>... > e = <optimized out> > attrs = {0x200072a0 "1.1", 0x0} > rc = 0 > nvalues = <optimized out> > res = 0x3fffa0001ac0 -- -- 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#8687) openldap fails to link w/ openssl 1.1 built w/ no-egd
by djkurtz＠google.com 07 Jul '17

07 Jul '17

Full_Name: Daniel Jonathan Kurtz Version: 2.4.45 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2401:fa00:1:b:dcfc:ce39:b80:8f26) openldap 2.4.45 fails to link when built against openssl 1.1 built w/ the default "no-egd" option: libtool: link: x86_64-cros-linux-gnu-clang -O2 -pipe -O2 -pipe -march=corei7 -g -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -clang-syntax -Wl,-O1 -Wl,-O2 -Wl,--as-needed -o .libs/ltest test.o ./.libs/libldap.so libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a -lssl -lcrypto -lresolv ./.libs/libldap.so: error: undefined reference to 'RAND_egd' RAND_egd does not exist because OpenSSL was built with the default settings which, as of 1.1, has "EGD" disabled by default [0]. [0] 0423f812dc Add a no-egd option to disable EGD-related code *) EGD is no longer supported by default; use enable-egd when configuring. [Ben Kaduv and Rich Salz] The RAND_egd reference is in libraries/libldap/tls_o.c: static int tlso_seed_PRNG( const char *randfile ) { #ifndef URANDOM_DEVICE /* no /dev/urandom (or equiv) */ long total=0; char buffer[MAXPATHLEN]; if (randfile == NULL) { /* The seed file is $RANDFILE if defined, otherwise $HOME/.rnd. * If $HOME is not set or buffer too small to hold the pathname, * an error occurs. - From RAND_file_name() man page. * The fact is that when $HOME is NULL, .rnd is used. */ randfile = RAND_file_name( buffer, sizeof( buffer ) ); } else if (RAND_egd(randfile) > 0) { /* EGD socket */ return 0; } if (randfile == NULL) { Debug( LDAP_DEBUG_ANY, "TLS: Use configuration file or $RANDFILE to define seed PRNG\n", 0, 0, 0); return -1; } ... It seems like we should be able to make the "else if (RAND_egd(randfile) > 0)" block conditional on "#if !defined(OPENSSL_NO_EGD)" to work around this issue

1 0

(ITS#8686) modrdn can't find the target dn if it is read directly from hdb backend
by yoshiho.yoshida＠synacor.com 06 Jul '17

06 Jul '17

Full_Name: Yoshiho Yoshida Version: 2.4.44 OS: CentOS 6.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.237.186.4) This issue only happens with hdb back-end database. If the target dn is not in the cache memory, then modrdn tries to get it from hdb using its normalized rdn. As this result, modrdn can't find the target dn with "No such attribute (16)" or "No such object (32)" error. no cache --> dn2id.bdb -- id --> id2entry.bdb The problem seems to exist in the buffer size to get id from dn2id.bdb. Test case uses uid as rdn and its syntax is SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} . Then this normalize is, 1) Normalization of UTF-8 (NKFC mormalization) 2) consecutive space characters to a single space 3) trim the ending space If the size of original rdn and normalized rdn is as follows, this problem occurs. len_rdn is the size of original rdn. len_norm_rdn is the size of normalized rdn. ((3 + len_norm_rdn) * 3) less than equal to ((3 + len_norm_rdn) + 1 + len_rdn + 1 + 8) Test case: 1. Test data $ cat zzz.ldif dn: dc=zzz dc: zzz objectClass: dcObject objectClass: organization o: zzz domain $ cat yyy.ldif dn: dc=yyy,dc=zzz o: yyy.zzz domain objectClass: dcObject objectClass: organization dc: yyy $ cat people.ldif dn: ou=people,dc=yyy,dc=zzz ou: people objectClass: organizationalRole cn: people $ cat xxx.ldif dn: uid=xxx,ou=people,dc=yyy,dc=zzz sn: xxx cn: xxx uid: xxx objectClass: inetOrgPerson $ 2. Add the above test data into ldap database (hdb) $ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password -f zzz.ldif ldap_initialize( ldap://192.168.10.131 ) add dc: zzz add objectClass: dcObject organization add o: zzz domain adding new entry "dc=zzz" modify complete $ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password -f yyy.ldif ldap_initialize( ldap://192.168.10.131 ) add o: yyy.zzz domain add objectClass: dcObject organization add dc: yyy adding new entry "dc=yyy,dc=zzz" modify complete $ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password -f people.ldif ldap_initialize( ldap://192.168.10.131 ) add ou: people add objectClass: organizationalRole add cn: people adding new entry "ou=people,dc=yyy,dc=zzz" modify complete $ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password -f xxx.ldif ldap_initialize( ldap://192.168.10.131 ) add sn: xxx add cn: xxx add uid: xxx add objectClass: inetOrgPerson adding new entry "uid=xxx,ou=people,dc=yyy,dc=zzz" modify complete $ o Verify the added dn $ ldapsearch -LL -x -h 192.168.10.131 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password uid=xxx version: 1 dn: uid=xxx,ou=people,dc=yyy,dc=zzz sn: xxx cn: xxx uid: xxx objectClass: inetOrgPerson $ 3. modify the above dn (rdn) $ cat modrdn_1.ldif uid=xxx,ou=people,dc=yyy,dc=zzz uid=\20a $ $ ldapmodrdn -v -x -r -h 192.168.10.131 -p 389 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password -f modrdn_1.ldif ldap_initialize( ldap://192.168.10.131:389 ) Renaming "uid=xxx,ou=people,dc=yyy,dc=zzz" new rdn="uid=\20a" (delete old rdn) Rename Result: Success (0) $ o Verify the changed rdn $ ldapsearch -LL -x -h 192.168.10.131 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password "uid= a" version: 1 dn: uid=\20a,ou=people,dc=yyy,dc=zzz sn: xxx cn: xxx objectClass: inetOrgPerson uid:: IGE= $ o Start the recurrence test 4. Restart the slapd to remove the cache $ ldap stop Killing slapd with pid 15740 done. $ $ tail /var/log/zimbra.log Jul 7 12:53:46 jpzcserv1 slapd[15740]: conn=1002 fd=18 closed (slapd shutdown) Jul 7 12:53:46 jpzcserv1 slapd[15740]: conn=1003 fd=20 closed (slapd shutdown) Jul 7 12:53:46 jpzcserv1 slapd[15740]: conn=1004 fd=22 closed (slapd shutdown) Jul 7 12:53:46 jpzcserv1 slapd[15740]: conn=1005 fd=24 closed (slapd shutdown) Jul 7 12:53:46 jpzcserv1 slapd[15740]: slapd shutdown: waiting for 0 operations/tasks to finish Jul 7 12:53:46 jpzcserv1 slapd[15740]: slapd stopped. $ $ ldap start Started slapd: pid 16998 $ $ tail /var/log/zimbra.log Jul 7 12:54:58 jpzcserv1 slapd[16997]: @(#) $OpenLDAP: slapd 2.4.44 (May 30 2017 23:19:56) $#012#011root@jpzcserv1.zimbra.jp:/home/yyoshida/zimbra/work/OpenLDAP_244/openldap-2.4.44/servers/slapd Jul 7 12:54:58 jpzcserv1 slapd[16998]: slapd starting $ 5. Then try to modify the rdn $ cat modrdn_2.ldif uid=\20a,ou=people,dc=yyy,dc=zzz uid=abc $ $ ldapmodrdn -v -x -r -h 192.168.10.131 -p 389 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password -f modrdn_2.ldif ldap_initialize( ldap://192.168.10.131:389 ) Renaming "uid=\20a,ou=people,dc=yyy,dc=zzz" new rdn="uid=abc" (delete old rdn) Rename Result: No such attribute (16) Additional info: modify/delete: uid: no such attribute $ Failed with " No such attribute (16)" 6. Then search the target dn to load the entry to cache $ ldapsearch -LL -x -h 192.168.10.131 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password "uid= a" version: 1 dn: uid=\20a,ou=people,dc=yyy,dc=zzz sn: xxx cn: xxx objectClass: inetOrgPerson uid:: IGE= $ 7. Again modify the same rdn $ ldapmodrdn -v -x -r -h 192.168.10.131 -p 389 -D 'uid=zimbra,cn=admins,cn=zimbra' -w password -f modrdn_2.ldif ldap_initialize( ldap://192.168.10.131:389 ) Renaming "uid=\20a,ou=people,dc=yyy,dc=zzz" new rdn="uid=abc" (delete old rdn) Rename Result: Success (0) $ Now it can be modified successfully. This problem found when the replica server needed to be restarted and it never synchronized with the master server because there are some bad dn data. The master server is also possible to have this problem if it needs to be restarted. Workaround) dn2id.c increase the size of data.ulen in hdb_dn2id() data.ulen = data.size * 3; d = op->o_tmpalloc( data.size * 3, op->o_tmpmemctx );

1 0

Re: (ITS#8685) Invalid memory access
by ryan＠nardis.ca 06 Jul '17

06 Jul '17

Hi Breno, Thanks a lot for taking the time to look at this. I reproduced the crash on a minicloud VM (thanks!) with gcc -O2 (but not -O1 or -O0) and also with clang -O2 and -O1 (but not -O0). On Fri, Jul 07, 2017 at 12:57:47AM +0000, leitao(a)debian.org wrote: >So, that is what I suppose is happening. On the following loop, >ldap_first_entry() is returning NULL, thus, i = 0; > > for ( i = 0, e = ldap_first_entxury( ld, res ); e != NULL; i++, e = ldap_next_entry( ld, e ) ) > { > values[ i ] = ldap_get_dn( ld, e ); > } > values[ i ] = NULL; > >Thus, value[0] = NULL; I have not been able to reproduce that. I added an assert(i == nvalues) here, but it never failed in the time I spent on this today. On IRC, Howard pointed at the computation of 'r' (line 682), and indeed some printf debugging suggests that may be going wrong. I occasionally saw values of 'r' greater than 'nvalues', leading to reads past the end of the array like you suggested. for example: nvalues = 19 [...] i=20 r=11 values[r]=0x10014fba0f0 i=48 r=6 values[r]=0x3fff40000bd0 i=49 r=3 values[r]=0x3fff40000b50 i=51 r=7 values[r]=0x3fff6c001310 i=46 r=11 values[r]=0x3fff0c003530 i=56 r=27 values[r]=0x25 Segmentation fault (core dumped) Unpacking the computation, it looks like the multiplication is the part that sometimes returns the wrong result. For example: nvalues = 19 [...] rand() -> 745824322 ((double)19)*745824322 -> 45495283642.000000 45495283642.000000 / 2147483648.000000 -> 21.185392 i=75 r=21 values[r]=0x35 Segmentation fault (core dumped) but 19.0*745824322 should be 14170662118. I'm not really sure where to look next. Compiler bug would be a nice explanation, but wouldn't it be unusual for gcc and clang to have the same bug?

1 0

Re: (ITS#8685) Invalid memory access
by leitao＠debian.org 06 Jul '17

06 Jul '17

Hello Howard, On Thu, Jul 06, 2017 at 08:55:01PM +0100, Howard Chu wrote: > leitao(a)debian.org wrote: > > Full_Name: Breno Leitao > > Version: upstream > > OS: Debian > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (32.104.18.202) > > > > > > Currently, do_random() function in tests/progs/slapd-mtread.c uses a random > > number (upto RAND_MAX) to access an array that is much smaller than RAND_MAX, > > causing a segfault. > > > > This causes a segmentation fault and more details could be found at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866122 > > > > > Thanks for the report. I've examined your proposed patch in your debian > bugtracker. It doesn't make much sense though. > > The random number is being correctly scaled, line 682: > > int r = ((double)nvalues)*rand()/(RAND_MAX + 1.0); > > Which means the value of r can only be from 0 to nvalues-1. > > And there should be no difference between nvalues and i, since on line 657: > > nvalues = ldap_count_entries( ld, res ); > > Since i is simply iterated through all of the entries in the response, the > two values cannot disagree. Thanks for looking at it, and your suggestion made me revisit it. let me share I am finding in the debug. This is the failure frame: #5 do_read (ld=0x3fff980008e0, entry=0x6e6d756c413d756f <error: Cannot access memory at address 0x6e6d756c413d756f>, attrs=0x20020058 <srchattrs>, noattrs=<optimized out>, maxloop=<optimized out>, maxretries=<optimized out>, force=<optimized out>, idx=<optimized out>, chaserefs=<optimized out>, delay=<optimized out>, nobind=<optimized out>) at ../../../../tests/progs/slapd-mtread.c:791 On this frame, these are the values we have: i = 0 do_retry = 0 rc = <optimized out> thrstr = "Read(1): entry=\"0 cnt: 1 (retried 0) (dc=example,dc=com)\000u=Alumni Association,ou=People,dc=example,dc=com)\000mple,dc=com)", '\000' <repeats 6641 times>... e = <optimized out> attrs = {0x200072a0 "1.1", 0x0} rc = 0 nvalues = <optimized out> res = 0x3fffa0001ac0 So, that is what I suppose is happening. On the following loop, ldap_first_entry() is returning NULL, thus, i = 0; for ( i = 0, e = ldap_first_entxury( ld, res ); e != NULL; i++, e = ldap_next_entry( ld, e ) ) { values[ i ] = ldap_get_dn( ld, e ); } values[ i ] = NULL; Thus, value[0] = NULL; Later, the do_random() code does the following loop and innerloop is 10000. for ( i = 0; i < innerloop; i++ ) { int r = ((double)nvalues)*rand()/(RAND_MAX + 1.0); do_read( ld, values[ r ], srchattrs, noattrs, nobind, 1, maxretries, delay, force, chaserefs, idx ); } Thus, independent of the r value, values[r] will have garbage, right? But I agree with you, I need to find a better patch that address this e = NULL corner case.

1 0

Re: (ITS#8685) Invalid memory access
by hyc＠symas.com 06 Jul '17

06 Jul '17

leitao(a)debian.org wrote: > Full_Name: Breno Leitao > Version: upstream > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (32.104.18.202) > > > Currently, do_random() function in tests/progs/slapd-mtread.c uses a random > number (upto RAND_MAX) to access an array that is much smaller than RAND_MAX, > causing a segfault. > > This causes a segmentation fault and more details could be found at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866122 > > Thanks for the report. I've examined your proposed patch in your debian bugtracker. It doesn't make much sense though. The random number is being correctly scaled, line 682: int r = ((double)nvalues)*rand()/(RAND_MAX + 1.0); Which means the value of r can only be from 0 to nvalues-1. And there should be no difference between nvalues and i, since on line 657: nvalues = ldap_count_entries( ld, res ); Since i is simply iterated through all of the entries in the response, the two values cannot disagree. Finally, such a simple bug as your patch suggests would have crashed long ago on every other machine/OS, and it has never done so. I don't believe you've identified the actual 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

(ITS#8685) Invalid memory access
by leitao＠debian.org 06 Jul '17

06 Jul '17

Full_Name: Breno Leitao Version: upstream OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (32.104.18.202) Currently, do_random() function in tests/progs/slapd-mtread.c uses a random number (upto RAND_MAX) to access an array that is much smaller than RAND_MAX, causing a segfault. This causes a segmentation fault and more details could be found at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866122

1 0

(ITS#8684) compiling 2.4.45 under AIX 7.1 fails
by huy.nguyen＠cegdim-activ.com 06 Jul '17

06 Jul '17

Full_Name: Huy Nguyen Version: 2.4.45 OS: AIX 7.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.6.223.9) After running configure and make depend, make fails with the following message : ./../../../libraries/liblmdb/mdb.c:4853:53: error: 'PTHREAD_MUTEX_ROBUST' undeclared (first use in this function) if (!rc) rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST); It appears AIX 7?1 doesn't have robust mutexes (https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.genpr…). Disabling robust mutexes with CPPFLAGS="-DMDB_USE_ROBUST=0" works fine.

1 0

(ITS#8683) SLAPD_META_CLIENT_PR hidden behind LDAP_DEVEL
by quanah＠openldap.org 05 Jul '17

05 Jul '17

Full_Name: Quanah Gibson-Mount Version: RE24 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The back-meta(5) man page discusses the following option: client-pr {accept-unsolicited|DISABLE|<size>} This feature allows one to use RFC 2696 Paged Results control when performing search operations with a specific target, irrespective of the client's request. When set to a numeric value, Paged Results control is always used with size as the page size. When set to accept-unsolicited, unsolicited Paged Results control responses are accepted and honored for compatibility with broken remote DSAs. The client is not exposed to paged results handling between slapd-meta(5) and the remote servers. By default (disabled), Paged Results control is not used and responses are not accepted. If set before any target specification, it affects all targets, unless overridden by any per-target directive. However, this feature is actually disabled by default, as it is #ifdef'd behind LDAP_DEVEL in back-meta.h: #ifdef LDAP_DEVEL #define SLAPD_META_CLIENT_PR 1 #endif /* LDAP_DEVEL */ So we need to determine if either: (a) The documentation should be removed from the man page, or (b) The feature should be enabled by default, and moved out from behind LDAP_DEVEL

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2017