Full_Name: Praveen Adini
OS: Alpine Containers
Submission from: (NULL) (188.8.131.52)
I'm trying to setup a openldap proxy wherein the proxy denies any search
requests for uid=root. When i tried using the rwm overlay to stop the
operation(#), i'm getting a segmentation fault although i see the unwilling to
perform operation 53 message being printed. here is the snippet of the conf that
rwm-rewriteRule "(.*)(uid=root)(.*)" "$1$2$3" "#"
Full_Name: Janne Peltonen
OS: Red Hat Enterprise Linux 7
Submission from: (NULL) (2001:708:110:1820:3664:a9ff:fe04:7363)
Proxied BINDs on back-ldap sometimes create Start TLS failed errors on the
connection from proxy to backend, and the client of the proxy receives the error
52. We had a look at the code, and it appears that in back-ldap/bind.c, the
timeout argument of the function ldap_back_start_tls always ends up as zero, so
the timeout tv.sec and tv.usec end up being set as 0 and 100000, respectively,
by the macro LDAP_BACK_TV_SET defined in back-ldap/back-ldap.h. This means that
the actual timeout waiting for starttls operation to complete will be 0.1
seconds, which is sometimes too little if there are latencies. We did a
quick&dirty hack to just set tv.sec to 3 and tv.usec to 0, and were no longer
able to get any Start TLS failed errors on the proxy bind.
We did find that the back-ldap has an "extended" timeout defined in
back-ldap/config.c - except that is commented out as "not implemented". Seems to
us that if that were implemented, you could set the timeout in your ldap
database section by something like "timeout extended=" and then you could have a
Steps to reproduce:
1. Configure an openldap proxy-backend pair, the proxy using the "ldap" database
and using ldap urls to connect to the backend (using ldaps urls might actually
be a workaround). Configure the binds to be proxied to the backend, too.
2. Create a script that creates multiple - say, 200 - simultaneous connections
to the proxy, using an ldaps url to connect to the proxy, and using the same DN
to bind as. (We haven't tried to connect to the frontend using ldap+starttls,
but I would suppose that would have a similar result, since the client
establishes TLS anyway before trying to bind to the proxy.)
3. Observe some of the binds fail (we typically get 5-6 fails for 200
simultaneous connection), with the client of the proxy getting a "Server is
unavailable: 52" type of error, and the proxy log containing lines such as
"conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed" after the BIND from
Possible workaround: Configure the proxy to use ldaps urls to the backend.
Suggested fix: Implement the "extended" timeout type in back-ldap/config.c
timeout_table, so that people can set the StartTLS timeout to a larger value
than the default 0.1 seconds.
References: discussion thread on the OpenLDAP-Technical mailing list.
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<body text="#000000" bgcolor="#FFFFFF">
<p><font face="Calibri">I reviewed some of the initial discussion
about this same issue which lead to this fix in version 2.4.26,
"</font>Fixed libldap ASYNC TLS setup (ITS#6828)", and looked at
the code that Ian Puleston suggested should be fixed in
ldap_int_open_connection. This routine does have the code to do
what was need for TSL to work but was not called since it received
an error code of -2 not 0. The -2 simply indicated that this was
an asynchronous call. I changed the test to call the TSL setup if
the return code was either 0 or -2. This fixes my issue. Here is
<p>--- openldap-2.4.47/libraries/libldap/open.c 2018-12-19
+++ openldap-2.4.47.mod/libraries/libldap/open.c 2019-01-26
@@ -440,7 +440,7 @@<br>
- if (rc == 0 && ( ld->ld_options.ldo_tls_mode ==
+ if ((rc == 0 || rc == -2) && (
ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD ||<br>
strcmp( srv->lud_scheme, "ldaps" ) == 0 ))<br>
++conn->lconn_refcnt; /* avoid premature free */<br>
--On Monday, January 28, 2019 3:35 PM +0000 Rupert Gallagher
> As you can see, I am using the default Apple linker, and hardened
> settings for the compiler. Try using those settings yourself, and see
> what comes out.
I tested on FreeBSD12 (since it uses clang rather than gcc) with the
following flags and the build completed w/o issue:
CFLAGS= -g -fstack-protector-all -fno-omit-frame-pointer -fPIC -fPIE -O2
-Wformat -Wformat-security -Werror=format-security
LDFLAGS= -Wl,-z,relro,-z,now -pie
CPPFLAGS= -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2
In any case, I think we've well established the problem you're hitting has
zero to do with OpenLDAP in and of itself. You'll need to take this up
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
As you can see, I am using the default Apple linker, and hardened settings =
for the compiler. Try using those settings yourself, and see what comes out=
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
On Monday, January 28, 2019 3:16 PM, Quanah Gibson-Mount <quanah(a)symas.com>=
> --On Monday, January 28, 2019 12:10 PM +0000 Rupert Gallagher
> ruga(a)protonmail.com wrote:
> > I can replicate your log when using the default tool-chain by Apple.
> > The following causes my system to fail with openldap, replicating my
> > original bug. The same settings succeed with many other open source
> > projects: openldap is the only one that fails.
> Then it sounds like OpenLDAP is tripping a bug in LLVM or related tools.
> Again, there are no duplicate symbols in the liblber library.
>> It builds just fine with zero issues.
>I'll believe you when I see your log.
Ah right, we're all just liars, and that's why it's so important for you to use our software.
Quit wasting our time. The burden of proof is on you to provide logs, not us.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/