- openldap-bugs - openldap.org

(ITS#7950) Memory leak issue
by kuldeep.itbhu＠gmail.com 25 Sep '14

25 Sep '14

Full_Name: Kuldeep Khare Version: 2.3.31 OS: Qnx URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.247.254.226) Hi, I am getting memory leak when calling below openldap api. I am using openldap-2.3.31 version. if(ldap_init()) { ldap_configure_client(mSession,clientip); int ldap_version = 3; ldap_set_option(mSession, LDAP_OPT_REFERRALS, LDAP_OPT_OFF); ldap_set_option(mSession, LDAP_OPT_PROTOCOL_VERSION, &ldap_version); // set timeout for every complete search ldap_set_option(mSession, LDAP_OPT_TIMELIMIT, &SMA_CERT_LDAP_SEARCH_TIMEOUT); // set timeout for any api call struct timeval api_timeout; api_timeout.tv_sec = SMA_CERT_LDAP_API_TIMEOUT; api_timeout.tv_usec = 0; struct timeval net_timeout; net_timeout.tv_sec = SMA_CERT_LDAP_NET_TIMEOUT; net_timeout.tv_usec = 0; ldap_set_option(mSession, LDAP_OPT_TIMEOUT, &api_timeout); ldap_set_option(mSession, LDAP_OPT_NETWORK_TIMEOUT, &net_timeout); } ldap_simple_bind(); //Only if init is successful ldap_result(); //only if init is successful ldap_unbind(); If anyone has encountered this issue please help. Thanks, Kuldeep

1 0

Re: (ITS#7949) Slapd deadlocks on connection
by quanah＠zimbra.com 25 Sep '14

25 Sep '14

--On Wednesday, September 24, 2014 10:39 PM +0000 quanah(a)openldap.org wrote: > 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) > Never mind, due to a code change that affected a feature backport I have privately. Closing this ITS. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(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 24 Sep '14

24 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 24 Sep '14

24 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

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

19 Sep '14

This is a cryptographically signed message in MIME format. --------------ms000401080109060103090807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > gabriel(a)gritsch-soft.com wrote: >> would it be possible to support Apples "Common Crypto Services" instea= d of >> OpenSSL > [..] > But in general, it sounds like a bad idea. In light of Apple's now-infa= mous=20 > "goto fail" bug=20 > http://www.zdnet.com/apples-goto-fail-tells-us-nothing-good-about-cuper= tinos-software-delivery-process-7000027449/=20 > it would be poor practice to migrate away from a security package that = is now=20 > receiving broad and in-depth scrutiny, to one that only has Apple's ass= urances=20 > behind it. Also given Apple's success rate with security in general=20 > http://online.wsj.com/articles/apple-celebrity-accounts-compromised-by-= very-targeted-attack-1409683803=20 > it seems like a poor choice. Yes, I agree with these concerns - especially for OpenLDAP server deploym= ents. But there are some advantages using the OS platform's mainstream crypto l= ib 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 so= me better access to smartcards. 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... Ciao, Michael. --------------ms000401080109060103090807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwOTE5MTgwNTU3WjAj BgkqhkiG9w0BCQQxFgQU1Bu1xvzhKvbO2C4/UC5TemE/oDIwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAJqysehHr7PX9CRn5k5b3vvjWRFBlZ267 gs5JFW7IRGga/8Qmd3OXCNpuAQIy1z3P92wxnT4jmRTtfym6t+dzicSqf7w6nORV76Y25I5d uz3t4Imzhe422I2DekCHSEKsYjI6D81+jz/zdBJxzDyFPnoxamcBeIzAqpZisMQmc59aNLTO JrzgCfsgzIJ5QkeLYIlyuCT2SgAtjdOakKSoVR36E++gfdMO9AjgJBHCuZsydYuMhiW40sDG 68+BthA3S5XqAf1S3xy3dPuVs08MhEnqPRcszILG2W/33LHcaxb1HuOpYfR44oxQfP01j9Wj v19+j+fkiLDwpEWhIfZFJgAAAAAAAA== --------------ms000401080109060103090807--

1 0

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

19 Sep '14

gabriel(a)gritsch-soft.com wrote: > Full_Name: Gabriel Gritsch > Version: 2.4.39 > OS: Mac OS X 10.9.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (46.234.244.166) > > > Hi all, > > would it be possible to support Apples "Common Crypto Services" instead of > OpenSSL because the OpenSSL-functions are marked as deprecated since OS X 10.7 > and produce a lot of warnings. If someone submits a patch for this we will of course review and consider it. 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. -- -- 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#7944) Apples Common Crypto Services instea of OpenSSL
by gabriel＠gritsch-soft.com 19 Sep '14

19 Sep '14

Full_Name: Gabriel Gritsch Version: 2.4.39 OS: Mac OS X 10.9.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (46.234.244.166) Hi all, would it be possible to support Apples "Common Crypto Services" instead of OpenSSL because the OpenSSL-functions are marked as deprecated since OS X 10.7 and produce a lot of warnings. best regards Gabriel

1 0

Re: (ITS#7943) LMDB fails to process transactions after map resize
by hyc＠symas.com 19 Sep '14

19 Sep '14

carlopires(a)gmail.com wrote: > Full_Name: Carlo Pires > Version: LMDB 0.9.14 > OS: Ubuntu Linux 14.04 LTS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (177.53.184.142) > > > LMDB 0.9.14 is refusing to process new transactions after map resize. The > following test case shows the error: Thanks for the report, fixed in mdb.master. > /* mtest7.c - memory-mapped database tester/toy */ > /* Tests for DB map resize */ > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > #include <assert.h> > #include "lmdb.h" > > #define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr) > #define EX(err, expr) CHECK((rc = (expr)) == (err), #expr) > #define RES(err, expr) ((rc = expr) == (err) || (CHECK(!rc, #expr), 0)) > #define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf(stderr, \ > "%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort())) > > int main(int argc,char * argv[]) > { > int rc; > MDB_env *env; > MDB_dbi dbi; > MDB_val key, data; > MDB_txn *txn; > MDB_envinfo minfo; > > char kval[32]; > char* sval = calloc(1, 8*1024*1024); > assert(sval); > > // create database > E(mdb_env_create(&env)); > E(mdb_env_set_mapsize(env, 10*1024*1024)); > E(mdb_env_set_maxdbs(env, 0)); > E(mdb_env_open(env, "./testdb", MDB_NORDAHEAD|MDB_NOLOCK|MDB_NOSYNC, 0664)); > > // starts dbi > E(mdb_txn_begin(env, NULL, 0, &txn)); > E(mdb_open(txn, NULL, MDB_CREATE, &dbi)); > E(mdb_txn_commit(txn)); > > // check database mapsize > E(mdb_env_info(env, &minfo)); > printf("map size is %ldMB\n%, C minfo.me_mapsize/1048576); > > // try to insert data > E(mdb_txn_begin(env, NULL, 0, &txn)); > > key.mv_size = sizeof(kval); > key.mv_data = &kval; > data.mv_size = 8*1024*1024; > data.mv_data = sval; > > sprintf(kval, "0"); > E(mdb_put(txn, dbi, %kekey, &data, 0)); > > sprintf(kval, "1"); > EX(MDB_MAP_FULL, mdb_put(txn, dbi, &key, &data, 0)); > > // abort transaction and increase map size > mdb_txn_abort(txn); > mdb_env_set_mapsize(env, 20*1024*1024); > > // check database mapsize > E(mdb_env_info(env, &minfo)); > printf("new map size is %ldMB\n", minfo.me_mapsize/1048576); > > // try to insert data again > E(mdb_txn_begin(env, NULL, 0, &txn)); > > sprintf(kval, "0"); > E(mdb_put(txn, dbi, &key, &data, 0)); > > sprintf(kval, "1"); > E(mdb_put(txn, dbi, &key, &data, 0)); > > E(mdb_txn_commit(txn)); > mdb_env_close(env); > > free(sval); > return 0; > } > > The code worked fine until LMDB 0.9.13. > > -- -- 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#7943) LMDB fails to process transactions after map resize
by carlopires＠gmail.com 19 Sep '14

19 Sep '14

--001a1135fa9258513c0503605842 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I forgot to attach the error message. Here is it: $ ./mtest7 map size is 10MB new map size is 20MB mtest7.c:69: mdb_put(txn, dbi, &key, &data, 0): MDB_BAD_TXN: Transaction cannot recover - it must be aborted Abortado (imagem do n=C3=BAcleo gravada) 2014-09-18 21:29 GMT-03:00 <openldap-its(a)openldap.org>: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#7943. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#7943) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#7943) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D7943 > > Please remember to retain your issue tracking number (ITS#7943) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --=20 Carlo Pires --001a1135fa9258513c0503605842 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>I forgot to attach the error message. Here is it: = </div> $ ./mtest7 <div>map size is 10MB new map size is 20MB mt= est7.c:69: mdb_put(txn, dbi, &key, &data, 0): MDB_BAD_TXN: Transact= ion cannot recover - it must be aborted Abortado (imagem do n=C3=BAcleo = gravada) </div></div><div class=3D"gmail_extra"> <div class=3D"gm= ail_quote">2014-09-18 21:29 GMT-03:00 <<a href=3D"mai= lto:openldap-its@openldap.org" target=3D"_blank">openldap-its(a)openldap.org<= /a>>: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#7943. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers.=C2=A0 They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#7943) in the subject will automatically be attached to the issue report. =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org">openldap-its(a)openldap.org</a>?subject=3D(ITS#7943) You may follow the progress of this report by loading the following URL in a web browser: =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D794= 3" target=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D7943</a= > Please remember to retain your issue tracking number (ITS#7943) on any further messages you send to us regarding this report.=C2=A0 If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" ta= rget=3D"_blank">http://www.OpenLDAP.org/support/</a> -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. </blockquote></div> -- =C2=A0 Carlo Pires </div> --001a1135fa9258513c0503605842--

1 0

(ITS#7943) LMDB fails to process transactions after map resize
by carlopires＠gmail.com 19 Sep '14

19 Sep '14

Full_Name: Carlo Pires Version: LMDB 0.9.14 OS: Ubuntu Linux 14.04 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (177.53.184.142) LMDB 0.9.14 is refusing to process new transactions after map resize. The following test case shows the error: /* mtest7.c - memory-mapped database tester/toy */ /* Tests for DB map resize */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <assert.h> #include "lmdb.h" #define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr) #define EX(err, expr) CHECK((rc = (expr)) == (err), #expr) #define RES(err, expr) ((rc = expr) == (err) || (CHECK(!rc, #expr), 0)) #define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf(stderr, \ "%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort())) int main(int argc,char * argv[]) { int rc; MDB_env *env; MDB_dbi dbi; MDB_val key, data; MDB_txn *txn; MDB_envinfo minfo; char kval[32]; char* sval = calloc(1, 8*1024*1024); assert(sval); // create database E(mdb_env_create(&env)); E(mdb_env_set_mapsize(env, 10*1024*1024)); E(mdb_env_set_maxdbs(env, 0)); E(mdb_env_open(env, "./testdb", MDB_NORDAHEAD|MDB_NOLOCK|MDB_NOSYNC, 0664)); // starts dbi E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_open(txn, NULL, MDB_CREATE, &dbi)); E(mdb_txn_commit(txn)); // check database mapsize E(mdb_env_info(env, &minfo)); printf("map size is %ldMB\n%, C minfo.me_mapsize/1048576); // try to insert data E(mdb_txn_begin(env, NULL, 0, &txn)); key.mv_size = sizeof(kval); key.mv_data = &kval; data.mv_size = 8*1024*1024; data.mv_data = sval; sprintf(kval, "0"); E(mdb_put(txn, dbi, %kekey, &data, 0)); sprintf(kval, "1"); EX(MDB_MAP_FULL, mdb_put(txn, dbi, &key, &data, 0)); // abort transaction and increase map size mdb_txn_abort(txn); mdb_env_set_mapsize(env, 20*1024*1024); // check database mapsize E(mdb_env_info(env, &minfo)); printf("new map size is %ldMB\n", minfo.me_mapsize/1048576); // try to insert data again E(mdb_txn_begin(env, NULL, 0, &txn)); sprintf(kval, "0"); E(mdb_put(txn, dbi, &key, &data, 0)); sprintf(kval, "1"); E(mdb_put(txn, dbi, &key, &data, 0)); E(mdb_txn_commit(txn)); mdb_env_close(env); free(sval); return 0; } The code worked fine until LMDB 0.9.13.

1 0

(ITS#7942) memory leak in control parsing
by hyc＠openldap.org 18 Sep '14

18 Sep '14

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (8.25.222.90) Submitted by: hyc A number of controls allocate additional structures in their parsing, stored in the op->o_controls[] array. Nothing cleans these up at the end of the operation. Usually these don't leak because they're allocated on the thread slab, but if the incoming request is large enough it can force them into regular malloc. Fix coming shortly.

1 0

(ITS#7941) crash in slap_bv2ad using repeated tags
by hyc＠openldap.org 18 Sep '14

18 Sep '14

Full_Name: Howard Chu Version: 2.4.x OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (8.25.222.90) Submitted by: hyc Fix coming shortly

1 0

Re: (ITS#6035) slapd requires restart after modifying olcAuthzRegexp
by ryan＠nardis.ca 17 Sep '14

17 Sep '14

Hi, Following up from <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761407#23>: This limitation seems to still exist (tried RE24 and master). Until it can be fixed, please document it clearly in slapd-config.5 (and maybe the admin guide too), as well as any related attrs if they also require a restart (olcAuthzPolicy?). It's surprising behaviour, since almost every other attribute does support online configuration. Proposed patch follows. thanks, Ryan diff --git a/doc/man/man5/slapd-config.5 b/doc/man/man5/slapd-config.5 index c5bf06f..7c39369 100644 --- a/doc/man/man5/slapd-config.5 +++ b/doc/man/man5/slapd-config.5 @@ -409,6 +409,10 @@ values can be specified to allow for multiple matching and replacement patterns. The matching patterns are checked in the order they appear in the attribute, stopping at the first successful match. +Note that changes to +.B olcAuthzRegexp +take effect the next time the server is started, not immediately upon +changing the configuration. .\".B Caution: .\"Because the plus sign + is a character recognized by the regular expression engine, .\"and it will appear in names that include a REALM, be careful to escape the

1 0

Re: (ITS#7940) Glue entry creation creates entries that cannot be found via ldapsearch filters
by quanah＠zimbra.com 17 Sep '14

17 Sep '14

--On Wednesday, September 17, 2014 3:08 AM +0100 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)openldap.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.39 >> OS: Linux 3.11 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.58.125) >> >> >> Found this at a customer site. They loaded an LDIF file that had the >> child of an entry, but not the entry itself. slapadd then created a >> glue entry to account for this, however there some significant problems >> with this process >> >> a) The glue entry is not syntactically correct. There is no RDN value. >> >> b) It is impossible to use a filter with ldapsearch to find the entry. >> It appears the objectClass index is utterly broken. > > Works as designed. Closing this ITS. Even with -M, it appears impossible to find a specific glued entry, which is problematic when attempting to find if it indeed exists or not outside of a slapcat, or trying to parse (in this case) the 306 broken glued entries that exist in the DB. It would be useful to be able (with -M) to actually search for and find the specific entry so that the account management client can then proceed accordingly. Right now, a search for the specific entry results in error code 32, so then the account management software attempts to create it, which results in error code 68. The software then has no way to find the entry and decide if it needs modification or deletion. OTOH, it is entirely the clients fault for providing bad input, so I'm not sure how hard we should chase it. :P --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7940) Glue entry creation creates entries that cannot be found via ldapsearch filters
by hyc＠symas.com 17 Sep '14

17 Sep '14

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 3.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) > > > Found this at a customer site. They loaded an LDIF file that had the child of > an entry, but not the entry itself. slapadd then created a glue entry to > account for this, however there some significant problems with this process > > a) The glue entry is not syntactically correct. There is no RDN value. > > b) It is impossible to use a filter with ldapsearch to find the entry. It > appears the objectClass index is utterly broken. Works as designed. Closing this ITS. > > Example entry, and the child that created it: > > dn: uid=abcd,ou=people,dc=xxxx,dc=com,dc=uy > entryUUID: a326899a-ad0e-1033-8edf-d9cf7a32cf04 > creatorsName: cn=config > createTimestamp: 20140731145640Z > entryCSN: 20140731145640.037371Z#000000#002#000000 > modifiersName: cn=config%momodifyTimestamp: 20140731145640Z > objectClass: top > objectClass: glue > structuralObjectClass: glue > > dn: zimbraDataSourceName=Adinet,uid=abcd,ou=people,dc=xxxx,dc=com,dc=uy > objectClass: zimbraDataSource > objectClass: zimbraImapDataSource > .... > > As we can see, the glue entry has no RDN attribute at all. It is also > impossible to find this entry via ldapsearch; > > ldapsearch -x -LLL -D $zimbra_ldap_userdn -w $zimbra_ldap_password -H $ldap_url > -b "ou=people,dc=xxxx,dc=com,dc=uy" uid=abcd > [zimbra@ldap01 ~]$ > > [zimbra@ldap01 ~]$ ldapsearch -x -LLL -D $zimbra_ldap_userdn -w > $zimbra_ldap_password -H $ldap_url -b "ou=people,dc=xxxx,dc=com,dc=uy" > "(objectClass=glue)" 1.1 > [zimbra@ldap01 ~]$ > > > > -- -- 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#7939) Unable to filter on "(objectClass=glue)"
by hyc＠symas.com 17 Sep '14

17 Sep '14

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 3.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) > > > When trying to find a set of broken entries, I found that it is impossible to > filter on objectClass=glue: > > [zimbra@ldap01 ~]$ ldapsearch -x -LLL -D $zimbra_ldap_userdn -w > $zimbra_ldap_password -H $ldap_url -b > "ou=people,dc=xxx,dc=xxx,dc=xxx%2%2"(objectClass=glue)" 1.1 > [zimbra@ldap01 ~]$ echo $? > 0 > > I am immediately returned to the prompt, and the error result is success (0). > Instead, I expect all the broken glue'd objects returned instead. Use the manageDSAit control. This works as designed, no bug, closing this ITS. -- -- 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#7940) Glue entry creation creates entries that cannot be found via ldapsearch filters
by quanah＠openldap.org 17 Sep '14

17 Sep '14

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 3.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) Found this at a customer site. They loaded an LDIF file that had the child of an entry, but not the entry itself. slapadd then created a glue entry to account for this, however there some significant problems with this process a) The glue entry is not syntactically correct. There is no RDN value. b) It is impossible to use a filter with ldapsearch to find the entry. It appears the objectClass index is utterly broken. Example entry, and the child that created it: dn: uid=abcd,ou=people,dc=xxxx,dc=com,dc=uy entryUUID: a326899a-ad0e-1033-8edf-d9cf7a32cf04 creatorsName: cn=config createTimestamp: 20140731145640Z entryCSN: 20140731145640.037371Z#000000#002#000000 modifiersName: cn=config%momodifyTimestamp: 20140731145640Z objectClass: top objectClass: glue structuralObjectClass: glue dn: zimbraDataSourceName=Adinet,uid=abcd,ou=people,dc=xxxx,dc=com,dc=uy objectClass: zimbraDataSource objectClass: zimbraImapDataSource .... As we can see, the glue entry has no RDN attribute at all. It is also impossible to find this entry via ldapsearch; ldapsearch -x -LLL -D $zimbra_ldap_userdn -w $zimbra_ldap_password -H $ldap_url -b "ou=people,dc=xxxx,dc=com,dc=uy" uid=abcd [zimbra@ldap01 ~]$ [zimbra@ldap01 ~]$ ldapsearch -x -LLL -D $zimbra_ldap_userdn -w $zimbra_ldap_password -H $ldap_url -b "ou=people,dc=xxxx,dc=com,dc=uy" "(objectClass=glue)" 1.1 [zimbra@ldap01 ~]$

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs