openldap-bugs October 2009

openldap-bugs@openldap.org

34 participants
223 discussions

Re: (ITS#6338) dnParent(x, x) can remove \0-termination
by h.b.furuseth＠usit.uio.no 20 Oct '09

20 Oct '09

masarati(a)aero.polimi.it writes: >> struct berval x = BER_BVC("cn=foo"); >> dnParent(x, x); >> keeps x.bv_val pointing at "cn=foo" instead of at the \0 >> behind it. bv_len is correctly set to 0 though. > > Could be sort of intentional. As far as I remember, dnParent() is > supposed to leave the second argument untouched, as it is often used > on read-only data. s/second/first/, but yes. With pdn=dn though (both args equal), the code first reset pdn->bv_val and then used that value. Swapping it makes more sense, and ensures that the output value is independent of whether or not pdn == dn. > Probably, the most appropriate fix consists in passing > a temporary as the first argument. No, the comment above the function says that pdn can be == dn. -- Hallvard

1 0

(ITS#6341) slapd crashing when deleting and re-adding the last object
by ralf＠OpenLDAP.org 20 Oct '09

20 Oct '09

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.30.227) Submitted by: ralf slapd in current HEAD and RE24 crashes when the last object from the database is deleted and re-added. Valgrind gives me this (during the ldapadd operation): ==11646== Invalid read of size 8 ==11646== at 0x52E4F2: bdb_cache_lru_link (cache.c:137) ==11646== by 0x530762: hdb_cache_add (cache.c:1191) ==11646== by 0x52C8D9: hdb_add (add.c:484) ==11646== by 0x44A43D: fe_op_add (add.c:334) ==11646== by 0x449DB0: do_add (add.c:194) ==11646== by 0x4410E6: connection_operation (connection.c:1123) ==11646== by 0x441672: connection_read_thread (connection.c:1259) ==11646== by 0x4E3C51C: ldap_int_thread_pool_wrapper (tpool.c:685) ==11646== by 0x6EB206F: start_thread (in /lib64/libpthread-2.9.so) ==11646== by 0x719A10C: clone (in /lib64/libc-2.9.so) ==11646== Address 0x9b25740 is 128 bytes inside a block of size 144 free'd ==11646== at 0x4C243AF: free (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==11646== by 0x5091C09: ber_memfree_x (memory.c:152) ==11646== by 0x465624: ch_free (ch_malloc.c:139) ==11646== by 0x52E493: bdb_cache_entryinfo_free (cache.c:104) ==11646== by 0x530E5A: hdb_cache_delete_cleanup (cache.c:1419) ==11646== by 0x5369A9: hdb_delete (delete.c:575) ==11646== by 0x462FDD: fe_op_delete (delete.c:174) ==11646== by 0x462C6C: do_delete (delete.c:95) ==11646== by 0x4410E6: connection_operation (connection.c:1123) ==11646== by 0x4E3C51C: ldap_int_thread_pool_wrapper (tpool.c:685) ==11646== by 0x6EB206F: start_thread (in /lib64/libpthread-2.9.so) ==11646== by 0x719A10C: clone (in /lib64/libc-2.9.so) Further investigation with gdb showed that bdb->bi_cache.c_lrutail points to free'd memory after the last object is removed from the database, which results in the crash when trying to access that memory during the add operation. I am currently working on a fix. Will submit it to HEAD later today.

1 0

(ITS#6340) What should I do it well?
by sunjian.xa＠gmail.com 20 Oct '09

20 Oct '09

Full_Name: sunjian Version: 2.4.16 OS: CentOS 4.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.114.169.6) hello, I am developing a ldap client program with kerberos V5 authentication under CentOS 4.7. Heimdal 0.7.2 is used for KDC, and OpenLDAP 2.4.16 for heimdal's backend. Cyrus SASL 2.1.22, OpenSSL 0.9.8b and BerkeleyDB 4.4.20 are also used. I compile OpenLDAP as follow, $env ol_enable_kbind=yes ./configure --prefix=/usr --localstatedir=/var/openldap --enable-syslog --enable-local --with-cyrus-sasl --with-threads --with-tls --with-kerberos --enable-crypt --enable-lmpasswd --enable-spasswd --enable-modules --enable-hdb --enable-ldap --enable-monitor --enable-dyngroup --enable-proxycache $make depend $make make[3]: Entering directory `/home/xk/download/openldap-2.3.24/servers/slapd/back-bdb' /bin/sh ../../..//libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -c bind.c cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -c bind.c -o bind.o bind.c: In function `bdb_bind': bind.c:154: error: syntax error before "goto" bind.c:161: error: syntax error before "goto" bind.c:176: error: syntax error before "goto" make[3]: *** [bind.lo] Error 1 make[3]: Leaving directory `/home/xk/download/openldap-2.3.24/servers/slapd/back-bdb' make[2]: *** [.backend] Error 1 make[2]: Leaving directory `/home/xk/download/openldap-2.3.24/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/xk/download/openldap-2.3.24/servers' make: *** [all-common] Error 1 Some one else told me that compiled with kbind, OpenLDAP should be patched and autoconf redone. Is that true? How to do in detail? If no kbind.o support, I have established the whole enviroment successfully. And the system works well. But I have to develop client program myself, so I need function ldap_kerberos_bind_s whose symbol included in kbind.o, then error occurs. Thanks.

1 0

Re: (ITS#6338) dnParent(x, x) can remove \0-termination
by masarati＠aero.polimi.it 20 Oct '09

20 Oct '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > This: > struct berval x = BER_BVC("cn=foo"); > dnParent(x, x); > keeps x.bv_val pointing at "cn=foo" instead of at the \0 > behind it. bv_len is correctly set to 0 though. Could be sort of intentional. As far as I remember, dnParent() is supposed to leave the second argument untouched, as it is often used on read-only data. Probably, the most appropriate fix consists in passing a temporary as the first argument. p.

1 0

Re: (ITS#6327) ldapsearch hangs
by quanah＠zimbra.com 19 Oct '09

19 Oct '09

--On Monday, October 19, 2009 3:46 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > This problem is also seen with Net::LDAPapi perl module, so it is library > rather than tool specific. It seems to be SASL specific as well (Stanford uses GSSAPI binds). I modified one of the problematic servers to have access to * by * read as its only ACL, and then did two searches. One using SASL/GSSAPI and one using anonymous query. The anonymous query succeeded across multiple runs. The SASL/GSSAPI query failed to complete. This was with a 2.4.19 ldapsearch binary against a remote 2.4.19 slapd. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6327) ldapsearch hangs
by quanah＠zimbra.com 19 Oct '09

19 Oct '09

Doing more investigation of this ITS reveals it appears to be related specifically to the version of ldapsearch used, and whether or not the connection actually goes over the network. Specifically, the result I see is: ldap_chkResponseList ld 0x510190 msgid -1 all 0 ldap_chkResponseList returns ld 0x510190 NULL ldap_int_select read1msg: ld 0x510190 msgid -1 all 0 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 52 ...R sasl_read: want=82, got=39 0000: 05 04 07 ff 00 00 00 1c 00 00 00 00 9d cb c2 05 ................ 0010: 43 a1 60 68 a0 f7 33 da d1 37 2f d8 21 4a 75 87 C.`h..3..7/.!Ju. 0020: b1 d8 73 41 ea 20 6b ..sA. k Working search shows: ldap_chkResponseList ld 2f798 msgid -1 all 0 ldap_chkResponseList returns ld 2f798 NULL ldap_int_select read1msg: ld 2f798 msgid -1 all 0 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 52 ...R sasl_read: want=82, got=82 0000: 05 04 07 ff 00 00 00 1c 00 00 00 00 6b be 1b 98 ............k... 0010: 17 5f 4a 09 70 15 23 cc 32 9f 71 6f eb 6e d2 66 ._J.p.#.2.qo.n.f 0020: b1 9a 56 61 4b 0a 64 83 ec a3 95 27 7d 07 87 5c ..VaK.d....'}..\ 0030: aa 37 26 a6 43 23 98 ab 60 e0 35 3b 7a f6 89 c2 .7&.C#..`.5;z... 0040: ca 7a 47 ec c2 0a 28 63 50 a8 16 da ae 55 fd 11 .zG...(cP....U.. 0050: ab 15 .. at which point it hangs. I've tried the following things: ldapsearch version 2.3.13 from a Solaris box. Searching with this version of ldapsearch never hangs, regardless of host location (remote machine room in Livermore, or local stanford machine room). ldapsearch version 2.4.11 from a linux box to ldap1 (2.4.19 server) hangs. These two boxes are in different locations/networks. ldapsearch 2.3.35 from ldap2 to ldap1 (2.4.19 server) hangs. These two boxes are on the same switch on the same vlan in the same building. ldapsearch 2.4.19 from ldap1 to ldap2 (2.3.35 server) does *not* hang. These two boxes are on the same switch on the same vlan in the same building. ldapsearch 2.4.19 from ldap1 to ldap-liv1 (2.4.19 server) hangs. So does the reverse direction. These two boxes are in very different locations. This problem is also seen with Net::LDAPapi perl module, so it is library rather than tool specific. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by quanah＠zimbra.com 19 Oct '09

19 Oct '09

--On Monday, October 19, 2009 10:32 PM +0000 openldap-its(a)OpenLDAP.org wrote: s/exist/exit --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6339) ldapsearch -V doesn't exist after version info
by quanah＠zimbra.com 19 Oct '09

19 Oct '09

Full_Name: Quanah Gibson-Mount Version: 2.4.19 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Executing ldapsearch -V to get the version information correctly prints it, but then proceeds to execute a search.

1 0

(ITS#6332)
by l.mierzwa＠gmail.com 19 Oct '09

19 Oct '09

Using accesslog overlay fixed my issues, without that not every change on=20 master is picked up by slaves. =C5=81ukasz

1 0

(ITS#6338) dnParent(x, x) can remove \0-termination
by h.b.furuseth＠usit.uio.no 19 Oct '09

19 Oct '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard This: struct berval x = BER_BVC("cn=foo"); dnParent(x, x); keeps x.bv_val pointing at "cn=foo" instead of at the \0 behind it. bv_len is correctly set to 0 though. Fixing.

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
23
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2009