openldap-bugs May 2016

openldap-bugs@openldap.org

20 participants
55 discussions

(ITS#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com 16 May '16

16 May '16

Full_Name: Maciej Puzio Version: 2.4.44 and git head OS: Ubuntu 16.04 amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.112.109.41) Incorrect handling of TLS options causes syncrepl to use different values for first connection attempt and subsequent retries. In some circumstances this may result in syncrepl unable to recover from a temporary network outage. Note: This bug has very similar symptoms and occurs in similar circumstances as ITS# 8385 (that has already been fixed). However, my investigation indicates that this is a separate issue. Steps to reproduce the problem: 1. Configure two LDAP servers in dual master replication setup using slapd.conf config file as described below. 2. Provide the servers with TLS certificates that are correct but do not include an address used in syncrepl provider setting. (Note: SECURE256 requires 4096-bit RSA key) 3. Set tls_reqcert to allow in both slapd.conf and ldap.conf. 4. Start slapd on both servers. 5. Stop and restart slapd on server A. 6. Server B will write errors to syslog: slapd: do_syncrep2: rid=001 (-1) Can't contact LDAP server slapd: do_syncrepl: rid=001 rc -1 retrying (9 reieies left) Expected result: After predefined time server B will retry replication, and we will see messages: slapd: do_syncrep1: rid=001 starting refresh slapd: do_syncrep1: rid=001 finished refresh Observed result: Server B produces theollolowing messages in a loop: slapd: do_syncrepl: rid=001 rc -1 retrying (8 retries left) slapd: slap_client_connect: URI=ldaps://10.0.0.1 DN="cn=root,dc=test" ldap_sasl_bind_s failed (-1) The relevant parts of slapd.conf: (for server A at 10.0.0.1) loglevel 1 serverID 001 moduleload syncprov TLSCipherSuite SECURE256:-VERS-SSL3.0 TLSCACertificateFile /etc/ldap/ssl/ca.pem TLSCertificateFile /etc/ldap/ssl/srvA.pemATATLSCertificateKeyFile /etc/ldap/ssl/srvA.key syncrepl rid=001 provider=ldaps://10.0.0.2 type=refreshAndPersist retry="30 10 300 +" searchbase="dc=test" attrs="*,+" bindmethod=simple binddn="cn=root,dc=test" credentials="plaintext-password" tls_reqcert=allow keepalive="240:5:10" mirrormode TRUE overlay syncprov syncprov-checkpoint 10 1440 OpenLDAP was build with this configuration: ./configure --prefix=/opt/openldap --enable-debug --enable-dynamic --enable-syslog --enable-local --enable-slapd --enable-crypt --enable-modules --enable-backends --enable-ndb=no --enable-shell=no --enable-perl=no --enable-sql=no --enable-wt=no --enable-overlays --with-tls=gnutls CPPFLAGS="-Wno-format-extra-args" Note that GnuTLS was used, following Debian and Ubuntu practice. I did not test this issue with other TLS libraries, and I do not know if this issue is GnuTLS-related or not. Debug findings: The above symptoms are caused by the following lines located at the end of ldap_int_tls_start in file libraries/libldap/tls2.c: if (ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_NEVER && ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_ALLOW) { ld->ld_errno = ldap_pvt_tls_check_hostname( ld, ssl, host ); if (ld->ld_errno != LDAP_SUCCESS) { return ld->ld_errno; } } The value of ld->ld_options.ldo_tls_require_cert is correct during first syncrepl connection attempt, but incorrect during retries. During my tests I noticed that it tended to equal 2 (demand), even when tls_reqcert was set to allow or never. On other occasions I noticed this variable to assume the value of TLS_REQCERT from ldap.conf, giving a peculiar result of first syncrepl connection using setting from slapd.conf, and subsequent ones from ldap.conf. It is possible that the value is uninitialized. Further debugging showed that this situation results from slap_client_connect (servers/slapd/config.c) not calling bindconf_tls_set on retries. The relevant code is: if ( sb->sb_tls_do_init ) { rc = bindconf_tls_set( sb, ld ); } else if ( sb->sb_tls_ctx ) { rc = ldap_set_option% l ld, LDAP_OPT_X_TLS_CTX, sb->sb_tls_ctx ); } Due to my limited familiarity with OpenLDAP design, I did not debug the issue further and did not find the root cause of this problem. Discusonon about relationship of this bug to ITS# 8385: On surface these bugs appear similar to each other like twins, both causing failures of syncrepl retries due to incorrect value of tls_reqcert. In fact, I found this bug while testing Ubuntu slapd and libldap packages with patch for #8385 backported. There are however some subtle differences: 1. A TLS certificate incorrect in a different way is needed to reproduce #8385: in my tests it listed a correct host, but had a key too weak for specified cipher strength. 2. Bug #8385 has much lower reproducibility (as expected for unallocated memory issue). 3. Symptoms of #8385 are a result of code in tls_g.c (tlsg_session_accept does wrong tests), while this bug results from host tests in tls2.c (ldap_int_tls_start). Both are triggered by an incorrect value of tls_reqcert. 4. I suspect a different cause leading to wrong tls_reqcert value in both bugs. Please let me know if you need further information. Thank you very much. Maciej Puzio

1 0

(ITS#8426) unable to get group names of user
by pradeepagrawal8184＠gmail.com 16 May '16

16 May '16

Full_Name: Pradeep Agrawal Version: 2.4.40-7 OS: centos URL: Submission from: (NULL) (114.143.121.177) is there any way to get groups of users by providing username. i am using java code to fetch list of groups of given users but it seems its not possible as user don't have 'memberof' attribute.

1 0

(ITS#8425) sssvlv active process
by pencilkhan07＠gmail.com 16 May '16

16 May '16

Full_Name: nilom khan Version: 2.4.40 OS: Centors 6.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.53.173.178) Dear sir , I know this is common problem but i can't able to solve it . Although previously some one suggest to add some code into /etc/ldap/sldap.conf . but my version doesn't contain /etc/openldap/sldap.conf . I google it and found that centors 6.5 version dos not contain this file. Below my version information . [root@mail ~]# slapd -V @(#) $OpenLDAP: slapd 2.4.40 (Nov 10 2015 09:41:16) $ mockbuild@c6b8.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.40 /openldap-2.4.40/build-servers/servers/slapd Could u please suggest me how to enable SSSVLV so that i can browse open ldap address book in outlook . Their have any process for search with group attribute ? its very kind full if you suggest me . Thanks in advance Nilom KHan

1 0

Re: (ITS#8423) Slapd hang when modifying the configuration and an accesslog purge is going on
by hyc＠symas.com 14 May '16

14 May '16

elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.4.43 > OS: RH7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.169.142.218) > > > When the accessLog is being purged, a change in cn=config will wait until the > purge is done, which may take a while. > > The access_log purge should honor cn=config pause requests. > Fixed now in git 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#8424) mdb_env_cwalk() is broken, leading to crash if MDB_CP_COMPACT is set
by hyc＠symas.com 14 May '16

14 May '16

ddmitrie(a)gmail.com wrote: > Full_Name: Dmitry Dmitrienko > Version: trunk, 0.9.18 > OS: Linux, Windows > URL: > Submission from: (NULL) (100.36.101.84) > Thanks, fixed now in git mdb.master > In short: > Reproduce: create a large database (1GB would be enough), run md_copy with -c > argument. Expected result - compacted new database, Actual result - empty new > database and crash in md_copy. > > In details: > mdb_env_cwalk() defines cursor and does not initialize most of its fields, > including mc_flags field. Then it calls mdb_page_get() procedure, which checks > if (C_ORIG_RDONLY|C_WRITEMAP) flags are set in mc_flags. Since this field is not > initialized, it may have arbitrary value. If these flags are not set, it starts > checking txn's mt_u.dirty_list, as if it was a writing transaction, while in > fact this is a walker, it is a reader, so it initialized mt_u.reader fields. > This field is in the same memory location with dirty_list just because it's > union. So mdb_page_get() actually reads lock file memory (it's where mt_u.reader > points to). If the database is large enough, it leads to access to far beyond > lock file memory mapped region and crashes md_copy. > > Proposed fix: > mdb_env_cwalk(mdb_copy *my, pgno_t *pg, int flags) > ... > + memset(&mc, 0, sizeof(mc)); > mc.mc_snum = 1; > mc.mc_top = 0; > mc.mc_txn = my->mc_txn; > + mc.mc.mc_flags = my->mc_txn->mt_flags & (C_ORIG_RDONLY|C_WRITEMAP); > > > > -- -- 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#8424) mdb_env_cwalk() is broken, leading to crash if MDB_CP_COMPACT is set
by ddmitrie＠gmail.com 14 May '16

14 May '16

Full_Name: Dmitry Dmitrienko Version: trunk, 0.9.18 OS: Linux, Windows URL: Submission from: (NULL) (100.36.101.84) In short: Reproduce: create a large database (1GB would be enough), run md_copy with -c argument. Expected result - compacted new database, Actual result - empty new database and crash in md_copy. In details: mdb_env_cwalk() defines cursor and does not initialize most of its fields, including mc_flags field. Then it calls mdb_page_get() procedure, which checks if (C_ORIG_RDONLY|C_WRITEMAP) flags are set in mc_flags. Since this field is not initialized, it may have arbitrary value. If these flags are not set, it starts checking txn's mt_u.dirty_list, as if it was a writing transaction, while in fact this is a walker, it is a reader, so it initialized mt_u.reader fields. This field is in the same memory location with dirty_list just because it's union. So mdb_page_get() actually reads lock file memory (it's where mt_u.reader points to). If the database is large enough, it leads to access to far beyond lock file memory mapped region and crashes md_copy. Proposed fix: mdb_env_cwalk(mdb_copy *my, pgno_t *pg, int flags) ... + memset(&mc, 0, sizeof(mc)); mc.mc_snum = 1; mc.mc_top = 0; mc.mc_txn = my->mc_txn; + mc.mc.mc_flags = my->mc_txn->mt_flags & (C_ORIG_RDONLY|C_WRITEMAP);

1 0

(ITS#8423) Slapd hang when modifying the configuration and an accesslog purge is going on
by elecharny＠apache.org 13 May '16

13 May '16

Full_Name: Emmanuel Lecharny Version: 2.4.43 OS: RH7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.169.142.218) When the accessLog is being purged, a change in cn=config will wait until the purge is done, which may take a while. A typical trace : ... Thread 7 (Thread 0x7f431bfff700 (LWP 57043)):D0D #0 0000007f4863858fdd in fdatasync () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f48619db98d in mdb_env_sync (env=0xc63d20, force=0) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/back-mdb/../../../libraries/liblmdb/mdb.c:2474 #2 0x00007f48619de46e in mdb_txn_commit (txn=0xc36ed0) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/back-mdb/../../../libraries/liblmdb/mdb.c:3572 #3 0x00007f48619c06c6 in mdb_delete (op=0x7f431bffe4c0, rs=0x7f431bffe450) at /home/build/sol_R_2.4.43.1/openldap/servs%s/slapd/back-mdb/delete.c:415 #4 0x00000000004d2b87 in overlay_op_walk (op=0x7f431bffe4c0, rs=0x7f431bffe450, which=op_delete, oi=0xc96a80, on=0x0) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/backover.c:677 #5 0x00000000004d2db4 in over_op_func (op=0x7f431bffe4c0, rs=0x7f431bffe450, which=op_delete) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/backover.c:730 #6 0x00000000004d2f6e in over_op_delete (op=0x7f431bffe4c0, rs=0x7f431bffe450) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/backover.c:787 #7 0x00007f486136dfb2 in accesslog_purge (ctx=0x7f431bffebb0, arg=0xc8ee00) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/overlays/accesslog.c:700 #8 0x00007f48656ff7f3 in ldap_int_thread_pool_wrapper (xpool=0xbd5d80) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/tpool.c:956 #9 0x00007f4864e89182 in start_thread (arg=0x7f431bfff700) at pthread_create.c:312 #10 0x00007f486386147d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 ... Thread 4 (Thread 0x7f1a7f7fc700 (LWP 57046)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f4865700ed3 in ldap_pvt_thread_cond_wait (cond=0xbd5ce0, mutex=0xbd5c88) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/thr_posix.c:277 #2 0x00007f48656ffcb6 in handle_pause (tpool=0x76b500 <connection_pool>, pause_type=96) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/tpool.c:1106 #3 0x00007f48656ffdb6 in ldap_pvt_thread_pool_pause (tpool=0x76b500 <connection_pool>) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/tpool.c:1152 #4 0x0000000000428c3b in config_back_modify (op=0x7f43040008e0, rs=0x7f431a7fba80) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/bconfig.c:5943 #5 0x0000000005e5e87e in fe_op_modify (op=0x7f43040008e0, rs=0x7f431a7fba80) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/modify.c:303 #6 0x000000000045e150 in do_modify (op=0x7f43040008e0, rs=0x7f431a7fba80) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/modify.c:177 #7 0x000000000043dcff in connection_operation (ctx=0x7f431a7fbbb0, arg_v=0x7f43040008e0) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/connection.c:1158 #8 0x000000000043e2a0 in connection_read_thread (ctx=0x7f431a7fbbb0, argv=0x63) at /home/build/sol_R_2.4.43.1/openldap/servers/slapd/connection.c:1294 #9 0x00007f48656ff7f3 in ldap_int_thread_pool_wrapper (xpool=0xbd5d80) at /home/build/sol_R_2.4.43.1/openldap/libraries/libldap_r/tpool.c:956 #10 0x00007864e4e89182 in start_thread (arg=0x7f431a7fc700) at pthread_create.c:312 #11 0x00007f486386147d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 The access_log purge should honor cn=config pause requests.

1 0

Re: (ITS#8422) --enable-ldap library linking failure
by hyc＠symas.com 13 May '16

13 May '16

jtrupp(a)symas.com wrote: > Full_Name: Jason Trupp > Version: 2.4.44 > OS: Ubuntu 12 and 14 > URL: > Submission from: (NULL) (173.173.23.148) > > > The --enable-ldap option, according to the Admin Guide section 12.3.1 is > required to make chaining work. However, enabling this feature as part of the > configuration does not automatically perform the library linking task,r%r > return an error if the linking were to fail for some reason. > > Per Howard Chu, "It worked at some time in the past. It's apparently broken > now..." > > Relevant Minutia: This bug report is inaccurate/incomplete. There is no linking problem when using configure --enable-ldap. Please provide accurate information on the issue you are reporting. -- -- 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#8422) --enable-ldap library linking failure
by jtrupp＠symas.com 11 May '16

11 May '16

Full_Name: Jason Trupp Version: 2.4.44 OS: Ubuntu 12 and 14 URL: Submission from: (NULL) (173.173.23.148) The --enable-ldap option, according to the Admin Guide section 12.3.1 is required to make chaining work. However, enabling this feature as part of the configuration does not automatically perform the library linking task,r%r return an error if the linking were to fail for some reason. Per Howard Chu, "It worked at some time in the past. It's apparently broken now..." Relevant Minutia: But when chaining via TLS, we get this error: 572be686 conn=1000 fd=14 ACCEPT from IP=127.0.0.1:41427 (IP=0.0.0.0:389) 572be686 conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037 572be686 conn=1000 op=0 STARTTLS 572be686 conn=1000 op=0 RESULT oid= err=0 text= 572be687 conn=1000 fd=14 TLS established tls_ssf=256 ssf=256 572be687 conn=1000 op=1 BIND dn="" method=163 572be687 conn=1000 op=1 BIND authcid="email=jtrupp(a)symas.com,cn=alcoa12,ou=alcoa,o=alcoa inc,l=riverdale,st=iowa,c=us" authzid="email=jtrupp(a)symas.com,cn=alcoa12,ou=alcoa,o=alcoa inc,l=riverdale,st=iowa,c=us" 572be687 conn=1000 op=1 BIND dn="email=jtrupp(a)symas.com,cn=alcoa12,ou=alcoa,o=alcoa inc,l=riverdale,st=iowa,c=us" mech=EXTERNAL sasl_ssf=0 ssf=256 572be687 conn=1000 op=1 RESULT tag=97 err=0 text= 572be687 conn=1000 op=2 MOD dn="cn=La Valko,ou=Peons,dc=example,dc=com" 572be687 conn=1000 op=2 MOD attr=description /usr/local/libexec/slapd: symbol lookup error: /usr/local/libexec/openldap/back_ldap-2.4.so.2: undefined symbol: ldap_modify_ext A checked against the libraries in use returns the following: root@alcoa12:/usr/local/etc/openldap# ldd /usr/local/libexec/openldap/back_ldap-2.4.so.2 linux-vdso.so.1 => (0x00007fff14b39000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc92c915000) /lib64/ld-linux-x86-64.so.2 (0x00007fc92cf17000) root@alcoa12:/usr/local/etc/openldap# ldd /usr/local/libexec/slapd linux-vdso.so.1 => (0x00007fffab493000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f18edf63000) libdb-5.3.so => /usr/lib/x86_64-linux-gnu/libdb-5.3.so (0x00007f18edbc1000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f18ed9a5000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f18ed748000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f18ed36d000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f18ed133000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f18ecf16000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f18ecb56000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f18ec951000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f18ec73a000) /lib64/ld-linux-x86-64.so.2 (0x00007f18ee187000)

1 0

Re: (ITS#8420) lmdb Windows sizeof(off_t) == sizeof(int32_t)
by hyc＠symas.com 10 May '16

10 May '16

clayton.stangeland(a)gmail.com wrote: > Full_Name: Clayton Stangeland > Version: lmdb master a04aad31c2 > OS: Windows 7 64 bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.54.58.5) > > > This is an lmdb bug. I see no bug here. We fixed this back in January in commit 20dec1f69bf4860202c764ce92b1fbbe3d11a065 > > mdb_page_flush fails as database size nears 2 GB on Windows. The reason is off_t > == int32_t on Windows. So the off_t pos variable becomes negative and this > section of code in mdb_page_flush enters the error condition as ov.OffsetHigh is > also negative: > > ov.Offset = pos & 0xffffffff; > ov.OffsetHigh = pos >> 16 >> 16; > if (!WriteFile(env->me_fd, dp, size, NULL, &ov)) { > rc = ErrCode(); > DPRINTF(("WriteFile: %d", rc)); > return rc; > } > > Adding23dedefine off_t int64_t in an #ifdef _WIN32 region solves this. > > > -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2016