openldap-bugs September 2010

openldap-bugs@openldap.org

26 participants
109 discussions

Re: (ITS#6645) Yet Another LDIF Wrap Patch
by hyc＠symas.com 09 Sep '10

09 Sep '10

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-09-ldif-wrap.1.… > Submission from: (NULL) (129.72.165.135) > Submitted by: ando > > > The subject should be self-explanatory. It is only exploited by slapcat, via > the -o ldif-wrap=<n> option (<n> < 0: default;<n> == 0: no wrap;<n> > 0: wrap > value); extending ldapsearch is trivial. > > I'm *NOT* going to commit this unless there is unanimous consensus ;) Not thrilled with the magic constant 2^31-1. Seems like you should have just used "if ( wrap && len > wrap )" instead of a word-size-dependent magic. -- -- 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#6598
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

Committed to HEAD; please test. Thanks, p.

1 0

ITS#6600
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

Applied (with changes) to HEAD; please test. Thanks, p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

>> Hello, >> we tested this (HEAD code): >> >> 1. ITS 6565 seems to be fixed: Chaining works now with correct search >> base. >> >> 2. If the target server of the chaining is not reachable we get "no such >> object", followed by a SIGSEV (core dump). Stack Trace: >> >> #0 0x0000000400040004 in ?? () >> #1 0x000000000042eb60 in slap_cleanup_play (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:436 >> #2 0x000000000043145a in send_ldap_response (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:621 >> #3 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:750 >> #4 0x00000000004e2154 in ldap_chain_response (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at chain.c:1132 >> #5 0x00000000004833f8 in over_back_response (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at backover.c:237 >> #6 0x000000000042eace in slap_response_play (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:402 >> #7 0x0000000000431437 in send_ldap_response (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:476 >> #8 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:750 >> #9 0x0000000000497adc in dnssrv_back_referrals (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at referral.c:118 >> >> 0x0000000400040004 is the address referenced in >> op->o_callback->sc_cleanup(op,rs) . > > Thanks for the report. It would be useful to know how that memory became > stale or dangling. Could you run slapd under valgrind and report any > error message related to accessing that memory? Thanks, p. I've checked a simple configuration (global instance of chain overlay; request for non existing entry, resulting in slapd returning the default referral), and nothing strange appeared (the offending instruction is executed). The issue might be specific to your configuration. You'll probably need to post more details. p.

1 0

(ITS#6645) Yet Another LDIF Wrap Patch
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-09-ldif-wrap.1.… Submission from: (NULL) (129.72.165.135) Submitted by: ando The subject should be self-explanatory. It is only exploited by slapcat, via the -o ldif-wrap=<n> option (<n> < 0: default; <n> == 0: no wrap; <n> > 0: wrap value); extending ldapsearch is trivial. I'm *NOT* going to commit this unless there is unanimous consensus ;) Enjoy. p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

> Hello, > we tested this (HEAD code): > > 1. ITS 6565 seems to be fixed: Chaining works now with correct search > base. > > 2. If the target server of the chaining is not reachable we get "no such > object", followed by a SIGSEV (core dump). Stack Trace: > > #0 0x0000000400040004 in ?? () > #1 0x000000000042eb60 in slap_cleanup_play (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:436 > #2 0x000000000043145a in send_ldap_response (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:621 > #3 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:750 > #4 0x00000000004e2154 in ldap_chain_response (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at chain.c:1132 > #5 0x00000000004833f8 in over_back_response (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at backover.c:237 > #6 0x000000000042eace in slap_response_play (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:402 > #7 0x0000000000431437 in send_ldap_response (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:476 > #8 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:750 > #9 0x0000000000497adc in dnssrv_back_referrals (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at referral.c:118 > > 0x0000000400040004 is the address referenced in > op->o_callback->sc_cleanup(op,rs) . Thanks for the report. It would be useful to know how that memory became stale or dangling. Could you run slapd under valgrind and report any error message related to accessing that memory? Thanks, p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by mlists＠keutel.de 09 Sep '10

09 Sep '10

Hello, we tested this (HEAD code): 1. ITS 6565 seems to be fixed: Chaining works now with correct search base. 2. If the target server of the chaining is not reachable we get "no such object", followed by a SIGSEV (core dump). Stack Trace: #0 0x0000000400040004 in ?? () #1 0x000000000042eb60 in slap_cleanup_play (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:436 #2 0x000000000043145a in send_ldap_response (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:621 #3 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:750 #4 0x00000000004e2154 in ldap_chain_response (op=0x7fffe40028c0, rs=0x7ffff1f70940) at chain.c:1132 #5 0x00000000004833f8 in over_back_response (op=0x7fffe40028c0, rs=0x7ffff1f70940) at backover.c:237 #6 0x000000000042eace in slap_response_play (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:402 #7 0x0000000000431437 in send_ldap_response (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:476 #8 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:750 #9 0x0000000000497adc in dnssrv_back_referrals (op=0x7fffe40028c0, rs=0x7ffff1f70940) at referral.c:118 0x0000000400040004 is the address referenced in op->o_callback->sc_cleanup(op,rs) . Regards, Jochen. Am 05.09.2010 18:01, schrieb masarati(a)aero.polimi.it: >> Hello, >> >>> Hi. I don't have time to work at this right now, but I think the >>> solution >>> would be to modify slapo-chain(5) so that when a referral's DN is "" and >>> the DN in the original request is not "", to use that DN instead. The >>> original request DN can be found in op->o_req_dn. >> >> we tested the following - with success: >> >> Just replace in servers/slapd/back-ldap/chain.c, function >> ldap_chain_op(), line 485-486: >> >> op->o_req_dn = pdn; >> op->o_req_ndn = ndn; >> >> With: >> >> if (pdn.bv_len> 0) { >> op->o_req_dn = pdn; >> } >> if (ndn.bv_len> 0) { >> op->o_req_ndn = ndn; >> } >> >> It would be great if this came into the official code. > > This issue was fixed consistently in HEAD code more than a month ago, > please test it and report, so in case it works the ITS can be closed and > the fix released. > > Thanks, p. >

1 0

Re: (ITS#6644) wrong conversion specifier for "port" in "ldap_domain2hostlist"
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

Fixed in HEAD. Thanks, p.

1 0

Re: (ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

> I've just tested this scenario using the back-meta sources (and > slap.h,sl_malloc.c) from HEAD. I also tried to add "tls start" to the > back-meta configuration. Not sure why you need those... > Unfortunately, the problem still persists. (But the workaround, > setting LDAPTLS_..., still works) > > When I look at the debug outputs (at debug level 1), the first > difference is in the SSL_connect messages. Only my workaround method > is sending the "write certificate verify" to authenticate with the > certificate, whereas it doesn't send this message without the > workaround. Can I see the entire configuration of both sides? (minus passwords and so, of course). Is the client using TLS? I'll re-check later, but I could use TLS-based EXTERNAL auth with both back-ldap and back-meta with and without setting "tls start". Just to make sure, can you pull the entire HEAD? Thanks for checking, in any case. p. > The Output from the "good" request (with workaround) is > ----------------------------------------------------------------------------------------- > TLS trace: SSL_connect:SSLv3 read server certificate A > TLS trace: SSL_connect:SSLv3 read server key exchange A > TLS trace: SSL_connect:SSLv3 read server certificate request A > TLS trace: SSL_connect:SSLv3 read server done A > TLS trace: SSL_connect:SSLv3 write client certificate A > TLS trace: SSL_connect:SSLv3 write client key exchange A > TLS trace: SSL_connect:SSLv3 write certificate verify A > TLS trace: SSL_connect:SSLv3 write change cipher spec A > TLS trace: SSL_connect:SSLv3 write finished A > TLS trace: SSL_connect:SSLv3 flush data > TLS trace: SSL_connect:SSLv3 read finished A > ldap_int_sasl_open: host=localhost > ldap_sasl_bind_s > ldap_sasl_bind > ldap_send_initial_request > ldap_send_server_request > ----------------------------------------------------------------------------------------- > > The output from the request without the workaround: > ----------------------------------------------------------------------------------------- > TLS trace: SSL_connect:SSLv3 read server certificate A > TLS trace: SSL_connect:SSLv3 read server key exchange A > TLS trace: SSL_connect:SSLv3 read server certificate request A > TLS trace: SSL_connect:SSLv3 read server done A > TLS trace: SSL_connect:SSLv3 write client certificate A > TLS trace: SSL_connect:SSLv3 write client key exchange A > TLS trace: SSL_connect:SSLv3 write change cipher spec A > TLS trace: SSL_connect:SSLv3 write finished A > TLS trace: SSL_connect:SSLv3 flush data > TLS trace: SSL_connect:SSLv3 read finished A > ldap_int_sasl_open: host=localhost > ldap_free_connection 1 1 > ldap_send_unbind > ber_flush2: 7 bytes to sd 15 > TLS trace: SSL3 alert write:warning:close notify > ldap_free_connection: actually freed > ----------------------------------------------------------------------------------------- > > Regards, > Manuel > > >

1 0

(ITS#6644) wrong conversion specifier for "port" in "ldap_domain2hostlist"
by mgaupp＠googlemail.com 09 Sep '10

09 Sep '10

Full_Name: Manuel Gaupp Version: 2.4.23 OS: Linux 2.6/x86 URL: Submission from: (NULL) (93.222.138.193) Hi, when using ldap_domain2hostlist to get informations from DNS SRV RRs, there is an issue for ports > 32767. For example, when a DNS SRV RR _ldap._tcp is referenced to port 63677 on a specific host, the returned hostlist contains port -1859. The error is caused by a wrong conversion in libldap/dnssrv.c, line 292. In this sprintf line, the unsigned short "port" is converted using "%hd" instead of "%hu". The attached patch should fix this issue (it did in my case). Regards, Manuel --- openldap-2.4.23-orig/libraries/libldap/dnssrv.c 2010-04-13 22:22:56.000000000 +0200 +++ openldap-2.4.23/libraries/libldap/dnssrv.c 2010-09-09 13:41:27.000000000 +0200 @@ -289,7 +289,7 @@ int ldap_domain2hostlist( /* not first time around */ hostlist[cur++] = ' '; } - cur += sprintf(&hostlist[cur], "%s:%hd", host, port); + cur += sprintf(&hostlist[cur], "%s:%hu", host, port); } add_size:; p += size;

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2010