openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

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

Re: (ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by mgaupp＠googlemail.com 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. 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. 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

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

09 Sep '10

The issue should be fixed in HEAD both for back-meta and back-ldap; now if TLS is required by idassert it will be started. Moreover, back-meta now allows to specify tls options per-target. The man page has not been updated yet. Please test and report through the ITS. Thanks, p.

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by quanah＠zimbra.com 09 Sep '10

09 Sep '10

--On Monday, September 06, 2010 3:11 AM +0200 masarati(a)aero.polimi.it wrote: > Should now be fixed in HEAD; platform independent, on Linux was not > failing but memory was being used incorrectly. ldapsearch-specific, no > issue in client library. Please test. Thanks, p. > I can confirm the issue no longer occurs with this patch in place. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#6642
by masarati＠aero.polimi.it 08 Sep '10

08 Sep '10

The problem is slightly different: the tls_* parameters of idassert are ignored unless TLS is started for other reasons. I believe back-meta needs to automatically start TLS for those connections created by idassert when idassert requires TLS for authentication. You can work this around by setting tls start this forces TLS to be started on all connections (tls try-start will fall back to non-TLS if it cannot be started). I note that there is an asymmetry between back-ldap and back-meta: the former allows to configure specific tls_* parameters for the "tls" statement. However, also back-ldap seems to require the "tls" statement to honor EXTERNAL TLS-based idassert. p.

1 0

(ITS#6643) back-meta silently retries anonymously in case of idassert with auth method not supported
by masarati＠aero.polimi.it 08 Sep '10

08 Sep '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.240) Submitted by: ando A fix is coming. p.

1 0

(ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by mgaupp＠googlemail.com 08 Sep '10

08 Sep '10

Full_Name: Manuel Gaupp Version: 2.4.23 OS: Linux 2.6/x86 URL: Submission from: (NULL) (93.222.169.203) Hi, as described in http://www.openldap.org/lists/openldap-technical/201009/msg00073.html using SASL EXTERNAL authentication within back-meta is not possible without the workaround to set some LDAPTLS_... environment variables. In http://www.openldap.org/lists/openldap-technical/201009/msg00085.html it is mentioned, that back-meta ignores the tls_... parameters for SASL EXTERNAL auth. I used the following configuration ------------------------------------------------- database meta suffix "dc=example" uri "ldaps://server2:636/cn=server2,dc=example" idassert-authzFrom "dn:*" idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_cert=mycert.crt tls_key=mycert.key tls_cacert=trusted-ca.pem mode=none ------------------------------------------------- At least, the options tls_cert,tls_key and tls_cacert should work properly to authenticate with TLS certificates. Thanks in advance Manuel Gaupp

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