openldap-bugs April 2015

openldap-bugs@openldap.org

29 participants
104 discussions

Re: (ITS#8093) Error string for LDAP_X_CONNECTING is missing
by hyc＠symas.com 01 Apr '15

01 Apr '15

mikko.auvinen(a)vincit.fi wrote: > Full_Name: Mikko Auvinen > Version: git master > OS: Windows 8.1 > URL: ftp://ftp.openldap.org/incoming/mikko-auvinen-150326.patch > Submission from: (NULL) (83.102.45.242) > > > ldap_search_ext() returns LDAP_X_CONNECTING when async connect attempt is > ongoing. > > ldap_err2string() is missing an error string for LDAP_X_CONNECTING so it's > returning "Unknown API error". > > Here's a patch that fixes this. > > Thanks, committed to master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8092) slapd crash with sasl auxprop and empty suffix
by hyc＠symas.com 01 Apr '15

01 Apr '15

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: master, 2.4 > OS: Debian > URL: > Submission from: (NULL) (24.68.37.4) > > > Based on a Debian bug report: https://bugs.debian.org/781162 > > ./configure --enable-spasswd > > cat > slapd.conf << EOF > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > database mdb > directory . > suffix "" > EOF > > slapadd -f slapd.conf << EOF > dn: dc=com > objectClass: domain > > dn: dc=example,dc=com > objectClass: domain > > dn: uid=test,dc=example,dc=com > objectClass: account > objectClass: simpleSecurityObject > userPassword: {SASL}test(a)EXAMPLE.COM > > EOF > > ldapwhoami -x -D uid=test,dc=example,dc=com > Enter LDAP Password: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffeebab700 (LWP 28815)] > __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 > 210 ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory. > (gdb) bt > #0 __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 > #1 0x0000000000441689 in select_backend (dn=0x7fffeebaa1a8, noSubs=1) at > backend.c:704 > #2 0x000000000049c7c2 in slap_auxprop_lookup (glob_context=0x0, > sparams=0x7fffe0001cd0, flags=0, > user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at sasl.c:370 > #3 0x00007ffff7bc463b in _sasl_auxprop_lookup (sparams=0x7fffe0001cd0, > flags=flags@entry=0, > user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at ../../lib/auxprop.c:959 > #4 0x00007ffff7bc5467 in _sasl_auxprop_lookup_user_props > (oparams=0x7fffe0001330, flags=3, conn=0x7fffe0000ac0) > at ../../lib/canonusr.c:220 > #5 _sasl_canon_user_lookup (conn=conn@entry=0x7fffe0000ac0, > user=user@entry=0x7fffe0001460 "test(a)EXAMPLE.COM", > ulen=ulen@entry=0, flags=flags@entry=3, > oparams=oparams@entry=0x7fffe0001330) at ../../lib/canonusr.c:281 > #6 0x00007ffff7bc5d39 in auxprop_verify_password (conn=0x7fffe0000ac0, > userstr=0x7fffe0001460 "test(a)EXAMPLE.COM", > passwd=0x7fffe0002696 "asdf", service=<optimized out>, user_realm=<optimized > out>) at ../../lib/checkpw.c:159 > #7 0x00007ffff7bcee78 in _sasl_checkpass (conn=conn@entry=0x7fffe0000ac0, > user=0x7fffe0001460 "test(a)EXAMPLE.COM", > userlen=userlen@entry=16, pass=pass@entry=0x7fffe0002696 "asdf", > passlen=passlen@entry=4) > at ../../lib/server.c:1922 > #8 0x00007ffff7bd1e50 in sasl_checkpass (conn=0x7fffe0000ac0, user=<optimized > out>, userlen=16, > pas3D0x0x7fffe0002696 "asdf", passlen=4) at ../../lib/server.c:1989 > #9 0x000000000049e4db in chk_sasl (sc=0x8cac98, passwd=0x7fffeebaa8a0, > cred=0x7fffe0002700, text=0x7fffeebaaae0) > at sasl.c:990 > #10 0x0000000000535278 in lutil_passwd (passwd=0x7fffe0003188, > cred=0x7fffe0002700, schemes=0x0, text=0x7fffeebaaae0) > at passwd.c:327 > #11 0x0000000000474aa6 in slap_passwd_check (op=0x7fffe00026b0, > e=0x7fffe0002f28, a=0x7fffe0002fa8, > cred=0x7fffe0002700, text=0x7fffeebaaae0) at passwd.c:529 > #12 0x00000000005088e7 in mdb_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at > bind.c:120 > #13 0x00000000004584f6 in fe_op_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at > bind.c:383 > #14 0x0000000000457bb4 in do_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at > bind.c:205 > #15 0x000000000042f68a in connection_operation (ctx=0x7fffeebaabf0, > arg_v=0x7fffe00026b0) at connection.c:1134 > #16 0x000000000042fc3a in connection_read_thread (ctx=0x7fffeebaabf0, argv=0xc) > at connection.c:1280 > #17 0x00000000005401bf in ldap_int_thread_pool_wrapper (xpool=0x8b83c0) at > tpool.c:958 > #18 0x00007ffff74750a4 in start_thread (arg=0x7fffeebab700) at > pthread_create.c:309 > #19 0x00007ffff71aa04d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > > I don't know how auxprop is intended to be configured; I'm going to follow up on > that when I have time. This is just about a segv that happens when > pwcheck_method is auxprop (the default) and the suffix is the empty string. Fundamentally this is a configuration error; you should not use SPASSWD with slapd's auxprop. I.e., slapd's auxprop is only intended for use when slapd handles all SASL authentication itself. Using SPASSWD means you're forwarding all SASL authentication to whatever external SASL mechanisms you have configured. In this particular case, slapd has forwarded the authentication request out to libsasl as you requested, and libsasl is forwarding it back into slapd's auxprop but without providing the context that slapd expects. Fixed now in master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8096) man not up to date
by quanah＠zimbra.com 01 Apr '15

01 Apr '15

--On Wednesday, April 01, 2015 6:13 PM +0000 tim.menage(a)gmail.com wrote: > Full_Name: Timothee > Version: @(#) $OpenLDAP: slapd (Ubuntu) (Mar 17 2014 21:20:08) > OS: Linux ldap 3.16.0-31-generic #41~14.04.1-Ubuntu SMP Wed Feb 11 > 19:30:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux URL: > ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.225.242.54) > > > Hey, > > If i've understand, slapd is reading config file from /etc/ldap/slapd.d/ > so I just don\t understand why when i do man slapd.conf (as you tell to do > everywhere), why the first lines are: > The file /etc/ldap/slapd.conf contains configuration information for the > slapd(8) daemon. Because both slapd-config(5) and slapd.conf(5) are supported. If you want the man page for slapd-config(5), read that one. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8096) man not up to date
by tim.menage＠gmail.com 01 Apr '15

01 Apr '15

Full_Name: Timothee Version: @(#) $OpenLDAP: slapd (Ubuntu) (Mar 17 2014 21:20:08) OS: Linux ldap 3.16.0-31-generic #41~14.04.1-Ubuntu SMP Wed Feb 11 19:30:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.225.242.54) Hey, If i've understand, slapd is reading config file from /etc/ldap/slapd.d/ so I just don\t understand why when i do man slapd.conf (as you tell to do everywhere), why the first lines are: The file /etc/ldap/slapd.conf contains configuration information for the slapd(8) daemon. Thanks

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2015