Re: (ITS#7381) Dynamically added chaining configuration stops working after restart
by hyc＠symas.com
Ivan Nejgebauer wrote:
> On 06.09.2013. 21:56, hyc(a)symas.com wrote:
>> ian(a)uns.ac.rs wrote:
>>> If a minimal chaining configuration is dynamically added to a consumer server in
>>> a provider/consumer pair running delta-syncrepl, it will stop working when the
>>> consumer is restarted. The configuration is modelled after the one used in
>>> test022 in the OpenLDAP source distribution:
>>
>> Sorry this report was neglected for so long, and thanks for the excellent test
>> case. This is now fixed in git master.
>
> Tested against git master (721e46fe6695077d63a3df6ea2e397920a72308d) with the original
> use case and it works, thanks. However, slapd now segfaults if started with cn=config
> obtained by converting an existing chaining configuration from slapd.conf. Steps to
> reproduce, using the scripts from the archive attached to the original report:
Ah thanks. Previous commit changed too much. Fixed now in master.
> $ make clean-all replica-chaining
> $ ./start-replica.sh # segfault
>
> The crash is in chain_ldadd, and occurs because the first back-ldap instance in the
> converted configuration lacks an olcDbURI. I have attached a patch which inserts a
> dummy URI in the common parameter structure when it's allocated. This URI
> (ldap://0.0.0.0) should never match any actual referral, so the instance can only
> serve to initialize common parameters (which happens with the first instance anyway,
> if I understood the code correctly.)
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 2 months
Re: (ITS#7381) Dynamically added chaining configuration stops working after restart
by ian＠uns.ac.rs
This is a multi-part message in MIME format.
--------------070406020601050207030907
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 06.09.2013. 21:56, hyc(a)symas.com wrote:
> ian(a)uns.ac.rs wrote:
>> If a minimal chaining configuration is dynamically added to a consumer server in
>> a provider/consumer pair running delta-syncrepl, it will stop working when the
>> consumer is restarted. The configuration is modelled after the one used in
>> test022 in the OpenLDAP source distribution:
>
> Sorry this report was neglected for so long, and thanks for the excellent test
> case. This is now fixed in git master.
Tested against git master (721e46fe6695077d63a3df6ea2e397920a72308d) with the original
use case and it works, thanks. However, slapd now segfaults if started with cn=config
obtained by converting an existing chaining configuration from slapd.conf. Steps to
reproduce, using the scripts from the archive attached to the original report:
$ make clean-all replica-chaining
$ ./start-replica.sh # segfault
The crash is in chain_ldadd, and occurs because the first back-ldap instance in the
converted configuration lacks an olcDbURI. I have attached a patch which inserts a
dummy URI in the common parameter structure when it's allocated. This URI
(ldap://0.0.0.0) should never match any actual referral, so the instance can only
serve to initialize common parameters (which happens with the first instance anyway,
if I understood the code correctly.)
--
Ivan Nejgebauer
Glavni sistem inženjer CIT-UNS/ARMUNS
Univerzitet u Novom Sadu
Trg Dositeja Obradovića 5
21000 Novi Sad +381 21 485 2025
ian(a)uns.ac.rs
www.uns.ac.rs
--------------070406020601050207030907
Content-Type: text/x-patch;
name="0001-Fix-crash-w-converted-chain-config.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="0001-Fix-crash-w-converted-chain-config.patch"
>From 49dc118a97cc5b7e0723905faf08480facb78912 Mon Sep 17 00:00:00 2001
From: Ivan Nejgebauer <ian(a)uns.ac.rs>
Date: Mon, 9 Sep 2013 11:33:02 +0200
Subject: [PATCH] Fix crash w/converted chain config
As a result of the fix for ITS#7381 (4d02a43ec9a4be422d83094e8d39b7ef3bc290c5)
slapd segfaults if started with dynamic configuration after converting
a slapd.conf chaining setup to cn=config. This is because the common
back-ldap parameters, emitted as the first olcDatabase entry, lack an
olcDbURI attribute. This patch adds a dummy LDAP URI which should never
match a real one (ldap://0.0.0.0) to the common parameter structure.
---
servers/slapd/back-ldap/chain.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/servers/slapd/back-ldap/chain.c b/servers/slapd/back-ldap/chain.c
index a7c53ed..ab71b21 100644
--- a/servers/slapd/back-ldap/chain.c
+++ b/servers/slapd/back-ldap/chain.c
@@ -2019,6 +2019,7 @@ ldap_chain_db_init_common(
BackendInfo *bi = be->bd_info;
ldapinfo_t *li;
int rc;
+ char *dummy_uri = "ldap://0.0.0.0";
be->bd_info = lback;
be->be_private = NULL;
@@ -2029,6 +2030,8 @@ ldap_chain_db_init_common(
li = (ldapinfo_t *)be->be_private;
li->li_urllist_f = NULL;
li->li_urllist_p = NULL;
+ li->li_uri = ch_strdup( dummy_uri );
+ li->li_bvuri = ch_calloc( sizeof( struct berval ), 1 );
be->bd_info = bi;
--
1.8.1.2
--------------070406020601050207030907--
10 years, 2 months
Re: (ITS#7678) Operational Error propagated from back-meta
by hyc＠symas.com
Matt Hamilton wrote:
> On 2 Sep 2013, at 04:15 PM, Howard Chu <hyc(a)symas.com> wrote:
>
>> matth(a)netsight.co.uk wrote:
>>> Full_Name: Matt Hamilton
>>> Version: 2.4.36
>>> OS: Linux
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (213.133.64.253)
>>>
>>>
>>> I am using the meta backend to query multiple LDAP (AD) backends. This is to
>>> consolidate several directories in different departments into one. We attempt
>>> both simple binds with username/password and also anon binds to look up user
>>> information.
>>
>> That doesn't make much sense, since AD disallows anonymous Binds.
>
> Sorry, I wasn't clear. I mean we do both anon and simple binds to OpenLDAP. Hence why the config has credentials in it to use against the backends if not supplied by the client.
>
>>> At the moment, trying to do an authenticated simple bind to slapd caused an
>>> Operational Error to be propagated to the client regardless of the setting of
>>> 'onerr'. Even when a result is successfully found. This is due to one server in
>>> the backend succeeding and the other returning an operational error due to an
>>> invalid bind (as would be expected as the credentials supplied from the client
>>> will only work with one of the backends).
>>>
>>> Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that
>>> the code is not checking for 'Operational Error' as a specific case above and so
>>> uses the default case (line 1665). Hence sres is set to 'Operational Error' too
>>> at line 1934.
>>
>> back-meta/search.c has nothing to do with Binds. Not sure what you're trying to demonstrate there.
>
> I'm not talking about binds there. I'm talking about errors being propagated.
You said, exactly:
>>>
At the moment, trying to do an authenticated simple bind to slapd caused an
Operational Error to be propagated to the client regardless of the setting of
'onerr'.
<<<
So again, are you talking about Bind or are you talking about Search?
I'm unable to reproduce any of the behavior you're describing since the config
snippets you provided reference servers that are private to your network. Nor
do I have any local AD servers to test against. Nor have you given exact
details of the client side commands being issued.
With so little ungarbled information to go on, we cannot investigate.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 2 months
Re: (ITS#7684) Admin Guide: Correct 'TLSEphemeralDHParamFile' to 'TLSDHParamFile'
by hyc＠symas.com
michael(a)stroeder.com wrote:
> Full_Name:
> Version: HEAD
> OS:
> URL:
> Submission from: (NULL) (79.219.124.115)
>
>
> The admin guide incorrectly mentions the configuration directive name
> 'TLSEphemeralDHParamFile' instead of 'TLSDHParamFile' like described in
> slapd.conf(5).
Thanks, fixed in master. (Also partly fixed in ITS#7506)
>
> See: http://www.openldap.org/doc/admin24/tls.html
>
> See this trivial patch:
>
> diff --git a/doc/guide/admin/aspell.en.pws b/doc/guide/admin/aspell.en.pws
> index 3683f98..9921963 100644
> --- a/doc/guide/admin/aspell.en.pws
> +++ b/doc/guide/admin/aspell.en.pws
> @@ -23,7 +23,7 @@ ddd
> DAs
> TLSCACertificateFile
> BNF
> -TLSEphemeralDHParamFile
> +TLSDHParamFile
> ppolicy
> gavin
> ASN
> diff --git a/doc/guide/admin/tls.sdf b/doc/guide/admin/tls.sdf
> index 00bf83c..9e3243e 100644
> --- a/doc/guide/admin/tls.sdf
> +++ b/doc/guide/admin/tls.sdf
> @@ -188,7 +188,7 @@ and it doesn't need very much data to work.
>
> This directive is ignored with GnuTLS and Mozilla NSS.
>
> -H4: TLSEphemeralDHParamFile <filename>
> +H4: TLSDHParamFile <filename>
>
> This directive specifies the file that contains parameters for
> Diffie-Hellman ephemeral key exchange. This is required in order
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 2 months
Re: (ITS#7500) libldap starttls crashes if invalid GnuTLS cipher suite string
by hyc＠symas.com
jouko.orava(a)iki.fi wrote:
> Full_Name: Jouko Orava
> Version: 2.4.28, 2.4.33
> OS: Debian/Ubuntu
> URL:
> Submission from: (NULL) (82.181.197.37)
>
>
> If the cipher suite string is unacceptable to GnuTLS, libldap_r-2.4 crashes in
> ldap_start_tls_s() due to a double free. See
> https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1103353
> for my original bug submission, including a suggested patch,
> https://launchpadlibrarian.net/129174364/openldap-ciphersuite.patch
> and a simple example ldapsearch-like program that can be used to test the
> issue.
This is now fixed in git master.
>
> This bug is not critical, since using a valid GnuTLS cipher suite does work, for
> example "NORMAL" or "SECURE256". However, trying to use anything more specific
> is exceedingly difficult -- basically trial and error, due to applications
> crashing in libldap with an invalid one.
>
> The two other TLS implementations in OpenLDAP are not affected by this bug.
>
> The double free occurs in
> openldap/libraries/libldap/tls2.c:ldap_int_tls_init_ctx(), in the
> ldap_pvt_tls_ctx_free(lo->ldo_tls_ctx); call in the error_exit: path. Because
> the cipher suite string was unacceptable to GnuTLS, the context is either
> released by GnuTLS or never properly initialized. The error_exit: path tries to
> release that context, and causes the C library to abort the program as it
> detects a double free.
>
> Simply commenting the ldap_pvt_tls_ctx_free(lo->ldo_tls_ctx); call in the
> error_exit: path in openldap/libraries/libldap/tls2.c:ldap_int_tls_init_ctx()
> masks the issue, but is obviously incorrect (as it affects the two other TLS
> implementations too).
>
> My suggested patch is to use the configured cipher suite string when creating
> the new TLS context, instead of "NORMAL" as is currently done, in
> openldap/libraries/libldap/tls_g.c:tlsg_ctx_new(). If there is a problem with
> the cipher suite priority string, the initial context is torn down, and caught
> earlier in openldap/libraries/libldap/tls2.c, avoiding the crash. (However, the
> cipher suite string will be parsed twice.)
>
> There seem to be numerous unhandled bug reports in various distributions and
> applications, including
> http://www.openldap.org/its/index.cgi/Incoming?id=6939#themesg
> which are quite tricky to investigate, as the actual bug occurs deep in libldap.
> Only user checks with a patched libldap will prove whether these are actually
> caused by this bug or not. It is very easy to assume it is an application bug,
> due to the symptoms and pretty limited circumstances.
>
> Recap: libldap + GnuTLS, application using ldap_start_tls, and any cipher suite
> string not acceptable to GnuTLS will cause libldap to crash due to a double
> free.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 2 months
Re: (ITS#7434) idassert-bind fails after restarting slapd
by hyc＠symas.com
blance3459(a)hotmail.com wrote:
> Full_Name: Barry Lance
> Version: 2.4.28
> OS: Ubuntu 12.04
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (70.226.37.226)
It appears the submitter found an alternate solution, but just for future
reference this issue was the same as ITS#7381, now fixed in git master.
>
> Two servers: Master (192.168.1.1) and Replica (192.168.1.2) both running slap
> 2.4.28 and ubuntu 12.04. Replica is a replication partner of Master using
> syncrepl. Replication is working fine. When I attempt to add a chain overlay
> to Replica to send all writes over to the master, it works exactly as expected
> allowing both normal users and the rootdn to make appropriate changes. However,
> once I either reboot the replica server or restart slapd, the chain overlay
> fails to allow any changes on the master. Looking at syslog shows that before
> the reboot/restart the requesting users' dn is proxied over as expected. After
> the restarting slapd or rebooting Replica, all changes are proxied anonymously
> (dn="").
>
> I am using simple binds at this point in the project, but it doesn't seems to
> matter if I proxy in the clear, ldaps, or TLS the result is the same. All three
> methods can successfully negotiate a connection. I've even tried switching
> between using the rootdn and a different user as the binddn in my overlay, but
> the result is still the same no matter what I use for the binddn. When I look
> at my config, I notice that "chain-idassert-bind" appears to be hashed or
> encrypted in thew config. Is that normal? Just seems really odd that my config
> would work immediately when added, but fail after the the daemon has been
> restarted. Am I missing something really silly? Hopefully, someone can assist
> me on this. I've been driving myself crazy trying to figure out why this
> behavior is occurring.
>
> Disclaimer: I am using openldap as part of my capstone project for graduation.
> I'm not asking for anyone to do my "homework" for me, I'm just stuck on this one
> issue that I would love to resolve so I can move on to the Kerberos phase of my
> project (and maybe even study for an exam coming up in my algorithms class next
> week).
>
> Here is my overlay config using the rootDN and TLS (on Replica):
>
> dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config
> changetype: add
> objectClass: olcLDAPConfig
> objectClass: olcChainDatabase
> olcDatabase: {0}ldap
> olcDbURI: "ldap://master.example.net/"
> olcDbRebindAsUser: TRUE
> olcDbIDAssertBind: bindmethod=simple
> binddn="cn=admin,dc=example,dc=net"
> credentials=(secret)
> mode=self
> starttls=critical
> tls_cacert=/etc/ssl/certs/cacert.pem
> tls_reqcert=demand
>
> And without TLS (also on Replica):
>
> dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config
> changetype: add
> objectClass: olcLDAPConfig
> objectClass: olcChainDatabase
> olcDatabase: {0}ldap
> olcDbURI: "ldap://master.example.net/"
> olcDbRebindAsUser: TRUE
> olcDbIDAssertBind: bindmethod=simple
> binddn="cn=admin,dc=example,dc=net"
> credentials=(secret)
> mode=self
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 2 months
