[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#8648) sasl_client_init called concurrently causes issues



Full_Name: Ryan Tandy
Version: RE24 (66d107e)
OS: Debian
URL: 
Submission from: (NULL) (24.68.41.160)
Submitted by: ryan


Test program uploaded to the FTP site:

ftp://ftp.openldap.org/incoming/20170427_rtandy_sasltest.c

I have built cyrus-sasl and openldap myself from clean sources in order to rule
out issues introduced by Debian patches. My environment is Debian unstable with
OpenSSL 1.0.2k.

cyrus-sasl master at 04dd838
./autogen.sh CFLAGS="-g -O0" --with-devrandom=/dev/urandom
make
sudo make install
sudo ldconfig
export SASL_PATH=/usr/local/lib/sasl2

openldap RE24 at 66d107e
./configure CFLAGS="-g -O0" --disable-backends --enable-mdb --disable-overlays
--with-cyrus-sasl --with-tls=openssl
make
sudo make STRIP= install
sudo ldconfig

cat > slapd.conf << 'eof'
include servers/slapd/schema/core.schema
include servers/slapd/schema/cosine.schema

sasl-secprops none
authz-regexp uid=(.*),cn=.*,cn=auth ldap:///dc=example,dc=com??sub?(uid=$1)

database mdb
directory .
suffix dc=example,dc=com
rootdn cn=root,dc=example,dc=com
index objectClass eq

eof

/usr/local/sbin/slapadd -f slapd.conf << eof
dn: dc=example,dc=com
objectClass: domain
dc: example

dn: uid=admin,dc=example,dc=com
objectClass: account
objectClass: simpleSecurityObject
uid: admin
userPassword: admin

eof

/usr/local/libexec/slapd -h ldap://:9000 -f slapd.conf -s0 -dstats

# allow PLAIN
export LDAPSASL_SECPROPS=none

# verify authz-regexp. should return uid=admin,dc=example,dc=com
ldapwhoami -H ldap://:9000 -Y PLAIN -U admin -w admin

# edit sasltest.c and change defines as needed. remove -DSASL to use simple
bind
cc -g -DSASL sasltest.c -pthread -llber -lldap -lsasl2 -o sasltest
./sasltest

On my system, most runs of ./sasltest result in errors like:

rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
Aborted

With no concurrency (THREADS defined to 1), I see no errors.

I believe this is due to sasl_client_init being called from multiple threads
concurrently. I suspect the global mech list is getting mucked with.

As a proof of concept, I patched libldap to call sasl_client_init during its
global init:

ftp://ftp.openldap.org/incoming/20170427_rtandy_call-sasl_client_init-in-global-init.patch

With this change, I see no errors.

If I'm right about this bug, I suppose the right fix is to wrap sasl_client_init
in a new mutex. I'll post a patch for review soon.