Re: ldap tls test fails in some environments

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ldap tls test fails in some environments
Date: 2020-05-14 04:47:03
Message-ID: CA+hUKG+_n-zt1EAZaZfojjXh9StROu+880pRrXVvtQTWEC_UMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 14, 2020 at 4:05 AM Christoph Berg <myon(at)debian(dot)org> wrote:
> Some other problem emerged here in the ldap test:

Hi Christoph,

> 17:28:59 Data directory: /<<PKGBUILDDIR>>/build/src/test/ldap/tmp_check/t_001_auth_node_data/pgdata

I know nothing about Debian package building so I could be missing
something about how this works, but I wonder if our script variable
handling is hygienic enough for paths like that. Let's see... I get
an error due to that when I run "make -C src/test/ldap check" from a
source tree under "/<<PKGBUILDDIR>>/build":

sh: 1: cannot create /build/src/test/ldap/tmp_check/slapd.pid:
Directory nonexistent

That's fixable with:

- kill 'INT', `cat $slapd_pidfile` if -f $slapd_pidfile;
+ kill 'INT', `cat "$slapd_pidfile"` if -f "$slapd_pidfile";

That's a side issue, though.

> 17:28:59 # TLS
> 17:28:59 not ok 19 - StartTLS
> 17:28:59 not ok 20 - LDAPS
> 17:28:59 not ok 21 - LDAPS with URL

> It consistently fails on the build server, but works on my notebook.
> Maybe that simply means slapd is crashing, but there's no slapd
> output. Would it be possible to start slapd with "-d 255", even if
> that means it doesn't background itself?

That'd require more scripting to put it in the background...

> 17:28:59 2020-05-13 15:28:58.479 UTC [31584] [unknown] LOG: could not start LDAP TLS session: Connect error

> 17:28:59 2020-05-13 15:28:58.728 UTC [31595] [unknown] LOG: could not perform initial LDAP bind for ldapbinddn "" on server "localhost": Can't contact LDAP server

Hmm, I get exactly the same errors as this if I comment out the
following part of the test script:

# don't bother to check the server's cert (though perhaps we should)
append_to_file(
$ldap_conf,
qq{TLS_REQCERT never
});

That's a file that we point to with the environment variable LDAPCONF.
The man page for ldap.conf says:

Thus the following files and variables are read, in order:
variable $LDAPNOINIT, and if that is not set:
system file /etc/ldap/ldap.conf,
user files $HOME/ldaprc, $HOME/.ldaprc, ./ldaprc,
system file $LDAPCONF,
user files $HOME/$LDAPRC, $HOME/.$LDAPRC, ./$LDAPRC,
variables $LDAP<uppercase option name>.
Settings late in the list override earlier ones.

This leads me to suspect that something in your build server's
environment that comes later in that list is overridding the
TLS_REQCERT setting. If that's the explanation, perhaps we should do
this, which seems to work OK on my system, since it comes last in the
list:

-$ENV{'LDAPCONF'} = $ldap_conf;
+$ENV{'LDAPTLS_REQCERT'} = "never";

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2020-05-14 05:09:46 Re: making update/delete of inheritance trees scale better
Previous Message Tom Lane 2020-05-14 02:52:29 Re: Another modest proposal for docs formatting: catalog descriptions