openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#7949) Slapd deadlocks on connection
by quanah＠openldap.org 24 Sep '14

24 Sep '14

Full_Name: Quanah Gibson-Mount Version: 2.4.40 OS: Linux 3.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.64.214) After deploying OpenLDAP 2.4.40, slapd becomes completely unresponsive, and every thread but the daemon is deadlocked Thread 10 (Thread 0x7fc4c7ba2700 (LWP 14910)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64%lolowlevellock.S:132 #1 0x00007fd8cc441065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at pthread_mutex_lock.c:61 #3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at thr_posix.c:296 #4 0x0000000000439470 in connection_get (s=10) at connection.c:278 #5 0x000000000043da27 in connection_write (s=10) at connection.c:1917 #6 0x000000000043804b in slapd_daemon_task (ptr=0x2749d38) at daemon.c:2757 #7 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c7ba2700) at pthread_create.c:308 #8 0x00007fd8cc16b3fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #9 0x0000000000000000 in ?? () Thread 9 (Thread 0x7fc4c73a1700 (LWP 14914)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007fd8ce078745 in ldap_pvt_thread_cond_wait (cond=0x302bd38, mutex=0x302bd10) at thr_posix.c:277 #2 0x0000000000451459 in send_ldap_ber (op=0x2c483c0, ber=0x7fc4c739f800) at result.c:377 #3 0x00000000004550ca in slap_send_search_entry (op=0x2c483c0, rs=0x7fc4c73a0a00) at result.c:1433 #4 0x000000000043f4ad in fe_op_search (op=0x2c483c0, rs=0x7fc4c73a0a00) at search.c:327 #5 0x000000000043f0c1 in do_search (op=0x2c483c0, rs=0x7fc4c73a0a00) at search.c:247 #6 0x000000000043b937 in connection_operation (ctx=0x7fc4c73a0b40, arg_v=0x2c483c0) at connection.c:1132 #7 0x000000000043bec9 in connection_read_thread (ctx=0x7fc4c73a0b40, argv=0xa) at connection.c:1268 #8 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at tpool.c:945 #9 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c73a1700) at pthread_create.c:308 #10 0x00007fd8cc16b3fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #11 0x0000000000000000 in ?? () Thread 8 (Thread 0x7fc4c6ba0700 (LWP 14915)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132 #1 0x00007fd8cc441065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at pthread_mutex_lock.c:61 #3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at thr_posix.c:296 #4 0x0000000000439470 in connection_get (s=10) at connection.c:278 #5 0x000000000043bfee in connection_read (s=10, cri=0x7fc4c6b9faf0) at connection.c:1310 #6 0x000000000043be2a in connection_read_thread (ctx=0x7fc4c6b9fb40, argv=0xa) at connection.c:1261 #7 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at tpool.c:945 #8 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c6ba0700) at pthread_create.c:308 #9 0x00007fd8cc16b3fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #10 0x0000000000000000 in ?? () ATAThread 7 (Thread 0x7fc4c639f700 (LWP 14916)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132 #1 0x00007fd8cc441065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at pthread_mutex_lock.c:61 #3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at thr_posix.c:296 #4 0x0000000000439470 in connection_get (s=10) at connection.c:278 #5 0x000000000043bfee in connection_read (s=10, cri=0x7fc4c639eaf0) at connection.c:1310 #6 0x000000000043be2a in connection_read_thread (ctx=0x7fc4c639eb40, argv=0xa) at connection.c:1261 #7 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at tpool.c:945 #8 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c639f700) at pthread_create.c:308 #9 0x00007fd8cc16b3fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #10 0x0000000000000000 in ?? () Thread 6 (Thread 0x7fc4c5b9e700 (LWP 22253)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132 #1 0x00007fd8cc441065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at pthread_mutex_lock.c:61 #3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at thr_posix.c:296 #4 0x0000000000439470 in connection_get (s=10) at connection.c:278 #5 0x000000000043bfee in connection_read (s=10, cri=0x7fc4c5b9daf0) at connection.c:1310 #6 0x000000000043be2a in connection_read_thread (ctx=0x7fc4c5b9db40, argv=0xa) at connection.c:1261 #7 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at tpool.c:945 #8 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c5b9e700) at pthread_create.c:308 #9 0x00007fd8cc16b3finin clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #10 0x0000000000000000 in ?? () Thread 5 (Thread 0x7fc4c539d700 (LWP 22254)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132 3231 0x000078c8cc441065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at pthread_mutex_lock.c:61 #3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at thr_posix.c:296 #4 0x0000000000439470 in connection_get (s=10) at connection.c:278 #5 0x000000000043bfee in connection_read (s=10, cri=0x7fc4c539caf0) at connection.c:1310 #6 0x000000000043be2a in connection_read_thread (ctx=0x7fc4c539cb40, argv=0xa) at connection.c:1261 #7 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at tpool.c:945 #8 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c539d700) at pthread_create.c:308 #9 0x00007fd8cc16b3fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #10 0x0000000000000000 in ?? () Thread 4 (Thread 0x7fc4c4b9c700 (LWP 22255)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007fd8ce078745 in ldap_pvt_thread_cond_wait (cond=0x302bce0, mutex=0x302bcb8) at thr_posix.c:277 #2 0x000000000043ab12 in connection_wake_writers (c=0x302bb80) at connection.c:765 #3 0x000000000043acb2 in connection_closing (c=0x302bb80, why=0x0) at connection.c:800 #4 0x000000000043bbff in connection_operation (ctx=0x7fc4c4b9bb40, arg_v=0x86b6940) at connection.c:1182 #5 0x000000000043bec9 in connection_read_thread (ctx=0x7fc4c4b9bb40, argv=0xa) at connection.c:1268 #6 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at tpool.c:945 #7 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c4b9c700) at pthread_create.c:308 #8 0x00007fd8cc16b3fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #9 0x0000000000000000 in ?? () Thread 3 (Thread 0x7fc4c439b700 (LWP 22256)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132 #1 0x00007fd8cc441065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at pthread_mutex_lock.c:61 #3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at thr_posix.c:296 #4 0x0000000000439470 in connection_get (s=10) at connection.c:278 #5 0x000000000043bfee in connection_read (s=10, cri=0x7fc4c439aaf0) at connection.c:1310 #6 0x000000000043be2a in connection_read_thread (ctx=0x7fc4c439ab40, argv=0xa) at connection.c:1261 #7 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at tpool.c:945 #8 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c439b700) at pthread_create.c:308 #9 0x00007fd8cc16b3fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #10 0x0000000000000000 in ?? () Thread 2 (Thread 0x7fc4c3b9a700 (LWP 22257)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132 #1 0x00007fd8cc441065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007fd8cc440eba in __pthread_mutex_lock (mutex=0x302bb98) at pthread_mutex_lock.c:61 #3 0x00007fd8ce078798 in ldap_pvt_thread_mutex_lock (mutex=0x302bb98) at thr_posix.c:296 #4 0x0000000000439470 in connection_get (s=10) at connection.c:278 #5 0x000000000043bfee in connection_read (s=10, cri=0x7fc4c3b99af0) at connection.c:1310 #6 0x000000000043be2a in connection_read_thread (ctx=0x7fc4c3b99b40, argv=0xa) at connection.c:1261 #7 0x00007fd8ce077043 in ldap_int_thread_pool_wrapper (xpool=0x2972000) at tpool.c:945 #8 0x00007fd8cc43ee9a in start_thread (arg=0x7fc4c3b9a700) at pthread_create.c:308 #9 0x00007fd8cc16b3fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #10 0x0000000000000000 in ?? () Thread 1 (Thread 0x7fd8ce727740 (LWP 14909)): #0 0x00007fd8cc440148 in pthread_join (threadid=140483141183232, thread_return=0x0) at pthread_join.c:89 #1 0x00007fd8ce078686 in ldap_pvt_thread_join (thread=140483141183232, thread_return=0x0) at thr_posix.c:197 #2 0x000000000043893a in slapd_daemon () at daemon.c:2907 #3 0x0000000000414b38 in main (argc=9, argv=0x7fff5361c928) at main.c:1012 (gdb)

1 0

(ITS#7948) mdb_copy insecure permissions
by geert＠hendrickx.be 24 Sep '14

24 Sep '14

Full_Name: Geert Hendrickx Version: 2.4.39 OS: centos6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.123.14.2) mdb_copy creates a copy using the default umask. This usually leads to insecure (world readable) copies, as typically an LDAP databse is 600 owned by some unprivileged ldap user. I suggest to copy the behaviour of cp, scp, rsync etc: preserve mode by default, preserve all metadata (uid:gid, mode, mtime, atime ...) when invoked with -p ?

1 0

Re: (ITS#7947) version skew? mdb_load: line 6: unrecognized keyword ignored: db_pagesize
by hyc＠symas.com 23 Sep '14

23 Sep '14

j.e.aten(a)gmail.com wrote: > Full_Name: Jason Aten > Version: LMDB 0.9.14 > OS: ubuntu 12.04 / amd64 > URL: > Submission from: (NULL) (2001:4807:2:104:d959:722c:ad90:ee70) > > > > There may have been version skew, because the mdb_load command does not > understand the output of the mdb_dump command. See the following error in the > context below. Works as designed. This message is not an error, otherwise the situation would not be "ignored." > "mdb_load: line 6: unrecognized keyword ignored: db_pagesize" The mdb_dump format is a copy of BDB's db_dump format, which needs the db_pagesize. Closing this ITS. > > jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_stat > var/lmdb_data > Status of Main DB > Tree depth: 1 > Branch pages: 0 > Leaf pages: 1 > Overflow pages: 0 > Entries: 1 > jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_stat -V > var/lmdb_data > LMDB 0.9.14: (September 15, 2014) > jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ which > mdb_stat > /usr/local/bin/mdb_stat > jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ ls -al `which > mdb_stat` > -rwxr-xr-x 1 root root 275324 Sep 18 03:17 /usr/local/bin/mdb_stat > jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_dump > var/lmdb_data/ > VERSION=3 > format=bytevalue > type=btree > mapsize=20971520 > maxreaders=126Ûdb_pagesize=4096 > HEADER=END > 00016d796b6579 > 6a61736f6e207761732068657265 > DATA=END > jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_dump > var/lmdb_data/ | mdb_load > usage: mdb_load dbpath [-V] [-f input] [-n] [-s name] [-N] [-T] > jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_dump > var/lmdb_data/ | mdb_load var/lmdb_data > mdb_load: line 6: unrecognized keyword ignored: db_pagesize > jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ > > -- -- 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

(ITS#7947) version skew? mdb_load: line 6: unrecognized keyword ignored: db_pagesize
by j.e.aten＠gmail.com 23 Sep '14

23 Sep '14

Full_Name: Jason Aten Version: LMDB 0.9.14 OS: ubuntu 12.04 / amd64 URL: Submission from: (NULL) (2001:4807:2:104:d959:722c:ad90:ee70) There may have been version skew, because the mdb_load command does not understand the output of the mdb_dump command. See the following error in the context below. "mdb_load: line 6: unrecognized keyword ignored: db_pagesize" jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_stat var/lmdb_data Status of Main DB Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 1 jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_stat -V var/lmdb_data LMDB 0.9.14: (September 15, 2014) jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ which mdb_stat /usr/local/bin/mdb_stat jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ ls -al `which mdb_stat` -rwxr-xr-x 1 root root 275324 Sep 18 03:17 /usr/local/bin/mdb_stat jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_dump var/lmdb_data/ VERSION=3 format=bytevalue type=btree mapsize=20971520 maxreaders=126Ûdb_pagesize=4096 HEADER=END 00016d796b6579 6a61736f6e207761732068657265 DATA=END jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_dump var/lmdb_data/ | mdb_load usage: mdb_load dbpath [-V] [-f input] [-n] [-s name] [-N] [-T] jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$ mdb_dump var/lmdb_data/ | mdb_load var/lmdb_data mdb_load: line 6: unrecognized keyword ignored: db_pagesize jaten@cutlass01:~/go/src/github.com/siddontang/ledisdb/store/mdb$

1 0

(ITS#7946) Update OID for Don't Use Copy Control
by michael＠stroeder.com 23 Sep '14

23 Sep '14

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (79.227.134.63) Please update constant LDAP_CONTROL_DONTUSECOPY in ldap.h to OID 1.3.6.1.1.22 as defined in RFC 6171 (Standards Track). Currently an experimental OpenLDAP .666 OID is used which makes this control rather unusable outside OpenLDAP implementation.

1 0

Re: (ITS#7797) crash with slapo-collect with existing attribute
by ondra＠mistotebe.net 23 Sep '14

23 Sep '14

On Fri, Feb 07, 2014 at 11:04:06PM +0000, danno(a)umich.edu wrote: > Requested stacktrace is below. Hi, I've uploaded a fix to ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20140923-ITS-7797.patch could you confirm it fixes the issue for you? Cheers, Ondrej

1 0

Re: (ITS#7945) attribute 'olcPPolicyDefault' not allowed(openldap password policy)
by quanah＠zimbra.com 22 Sep '14

22 Sep '14

--On Monday, September 22, 2014 8:55 AM +0000 q03765(a)sohu.com wrote: > Full_Name: Crane.YQ.Feng > Version: 2.4.23 > OS: redhat linux 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (218.29.136.228) > > > Hello openldap Expert, > Could anyone do me a big favor. when i config my openldap's function > about the password policy and to define the " olcPPolicyDefault ", a > problem has occurted?? The ITS system is for reporting bugs, not asking usage questions. Use the openldap-technical list for asking questions. This ITS will be closed. -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7945) attribute 'olcPPolicyDefault' not allowed(openldap password policy)
by q03765＠sohu.com 22 Sep '14

22 Sep '14

Full_Name: Crane.YQ.Feng Version: 2.4.23 OS: redhat linux 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (218.29.136.228) Hello openldap Expert, Could anyone do me a big favor. when i config my openldap's function about the password policy and to define the " olcPPolicyDefault ", a problem has occurted¡£ Note(The enldldap has configed ,it is worked on cn=config model) when i add a password default policy entry(olcPPolicyDefault) in to my openldap database(cn=config). the system returned a error message : ------------------------------------------------------------------------------------ file content(olcPPolicy-new.ldif): dn: cn=config changetype: modify add: olcPPolicyDefault olcPPolicyDefault: cn=default,ou=policies,dc=ldap,dc=idpbg,dc=com [root@GL-LDAP01 data]# ldapmodify -Y EXTERNAL -H ldapi:/// -f olcPPolicy-new.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Object class violation (65) additional info: attribute 'olcPPolicyDefault7 7 not allowed Used another way to add this entry,the problem is same: ----------------------------------------------------------------------------- olcPPolicyDefault.ldif file content: dn: cn=config changetype: add olcPPolicyDefault: cn=default,ou=policies,dc=ldap,dc=idpbg,dc=com [root@GL-LDAP01 data]# ldapmodify -Y EXTERNAL -H ldapi:/// -f olcPPolicyDefault.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=config" ldap_add: Object class violation (65) additional info: no objectClass attribute So I can't add olcPPolicyDefault to make openldap password policy to available. attachment: ---------------------------------- cn=config content: [root@GL-LDAP01 openldap]# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(olcoverlay=ppolicy))" dn: olcOverlay={1}ppolicy,olcDatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {1}ppolicy olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: FALSE [root@GL-LDAP01 openldap]# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config))" dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: /etc/openldap/slapd.conf olcConfigDir: /etc/openldap/slapd.d/ olcAllows: bind_v2 olcArgsFile: /var/run/openldap/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 71 olcLogLevel: Trace olcLogLevel: Packets olcLogLevel: Args olcLogLevel: Conns olcLogLevel: BER olcLogLevel: Filter olcLogLevel: Config olcLogLevel: ACL olcLogLevel: Stats olcLogLevel: Stats2 olcLogLevel: Shell olcLogLevel: Parse olcPidFile: /var/run/openldap/slapd.pid olcReadOnly: FALSE olcReverseLookup: FALSE olcSaslSecProps: noplain,noanonymous olcServerID: 1 ldap://GL-LDAP01.ldap.idpbg.com olcServerID: 2 ldap://GL-LDAP02.ldap.idpbg.com olcServerID: 3 ldap://TY-LDAP01.ldap.idpbg.com olcServerID: 4 ldap://TY-LDAP02.ldap.idpbg.com olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificateFile: /etc/pki/tls/certs/ca-bundle.crt olcTLSCertificateFile: /etc/pki/tls/certs/slapd.pem olcTLSCertificateKeyFile: /etc/pki/tls/certs/slapd.pem olcTLSVerifyClient: never olcToolThreads: 1 olcWriteTimeout: 0

1 0

Re: (ITS#7944) Apples Common Crypto Services instea of OpenSSL
by michael＠stroeder.com 19 Sep '14

19 Sep '14

hyc(a)symas.com wrote: > Michael Ströder wrote: >> On the downside it's a pain to deal with all the LDAP_OPT_X_TLS_* options >> having no or different meaning/features for various crypto libs... > > Indeed. Even moreso if, as you seem to be suggesting, a client library gets > built against a different TLS API than the server side. The current libldap > infrastructure wouldn't even support such a build. (Although it could, as the > original version of modular TLS support allowed all of the libraries to be > supported concurrently. But we dropped that feature because there was no sane > usecase for it.) Personally I'd even prefer to have completely different LDAP_OPT_X_TLS_* values and configuration directives for the different crypto APIs. In this case one could really distinguish the different cases. E.g. pointing to an OpenSSL CA certificate path is something completely different than a libnss cert7.db/key3.db directory regarding the content even though in both cases the option just is a directory path. IMHO this would avoid a lot of the user/deployer confusion one can see on the mailing lists. Well, for discussing this openldap-devel list would be the better forum. > The real solution, if there are platform-specific keystores and such that you > want to gain access to, is to submit patches for them to the OpenSSL project. Hmm, openssl engine things are not really easy to deal with. I know that PKCS#11 engine for OpenSSL exists. But such a stack has lots of loose ends. Ciao, Michael.

1 0

Re: (ITS#7944) Apples Common Crypto Services instea of OpenSSL
by hyc＠symas.com 19 Sep '14

19 Sep '14

Michael Ströder wrote: > hyc(a)symas.com wrote: >> gabriel(a)gritsch-soft.com wrote: >>> would it be possible to support Apples "Common Crypto Services" instead of >>> OpenSSL >> [..] >> But in general, it sounds like a bad idea. In light of Apple's now-infamous >> "goto fail" bug >> http://www.zdnet.com/apples-goto-fail-tells-us-nothing-good-about-cupertino… >> it would be poor practice to migrate away from a security package that is now >> receiving broad and in-depth scrutiny, to one that only has Apple's assurances >> behind it. Also given Apple's success rate with security in general >> http://online.wsj.com/articles/apple-celebrity-accounts-compromised-by-very… >> it seems like a poor choice. > > Yes, I agree with these concerns - especially for OpenLDAP server deployments. > > But there are some advantages using the OS platform's mainstream crypto lib > for libldap to get access to the OS's own keyring (e.g. when using client certs). > > E.g. I'd avoid libnss for OpenLDAP servers but PKCS#11 in libnss gives some > better access to smartcards. OK, that may be nice to have. OpenSSL's engine API already allows such things to be supported dynamically, though. > On the downside it's a pain to deal with all the LDAP_OPT_X_TLS_* options > having no or different meaning/features for various crypto libs... Indeed. Even moreso if, as you seem to be suggesting, a client library gets built against a different TLS API than the server side. The current libldap infrastructure wouldn't even support such a build. (Although it could, as the original version of modular TLS support allowed all of the libraries to be supported concurrently. But we dropped that feature because there was no sane usecase for it.) The real solution, if there are platform-specific keystores and such that you want to gain access to, is to submit patches for them to the OpenSSL project. -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs