openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#8700) Compile error
by papachoco＠gmail.com 27 Jul '17

27 Jul '17

Full_Name: Carlos Sanchez Version: 2.4.45 OS: macOS 10.12.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.97.40.67) I am getting the error below while compiling openldap 2.4.45 on the latest macOS sierra (10.12.6). I am only setting two configuration options configure-options = --disable-slapd --disable-slurpd Undefined symbols for architecture x86_64: "_ERR_remove_thread_state", referenced from: _tlso_destroy in libldap.a(tls_o.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [apitest] Error 1 make[1]: *** [all-common] Error 1 make: *** [all-common] Error 1 openldap_client: Command failed with exit code 2: make

1 0

(ITS#8699) More for cursor_del with DUPSORT
by hyc＠openldap.org 26 Jul '17

26 Jul '17

Full_Name: Howard Chu Version: LMDB 0.9.21 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.216.236.133) Submitted by: hyc When deleting a series of records in a loop using mdb_cursor_get(MDB_NEXT) in a DUPSORT DB, when deleting the last dup of one key, the first dup of the next key gets skipped on the next iteration. This appears to be due to an incomplete fix to ITS#8622

1 0

(ITS#8698) ppolicy: responses from pwdCheckModule discarded when using an extended password modify
by tim＠bishnet.net 26 Jul '17

26 Jul '17

Full_Name: Tim Bishop Version: 2.4.42 OS: Ubuntu 16.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:630:340:1141::13) Whilst this issue was discovered on OpenLDAP 2.4.42, the code is unchanged on the latest version, so I believe it is still applicable there. The high-level overview of the problem is that when using the ppolicy overlay with an external pwdCheckModule, and a password is changed using the LDAPv3 Password Modify (RFC 3062) extended operation (ie. ldappasswd), the message returned by the pwdCheckModule is not passed back to the user. All other failure messages generated in ppolicy are returned correctly. I've looked into this and discovered the cause of the problem. We can start by looking at where the message is returned: https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_42/servers/s… The check_password_quality function calls out to the pwdCheckModule which sets txt to point at a malloc'd string. Here we set rs->sr_text to point to that, and make a note to free it later. This is the exception, in all other cases, as can be seen a few lines below, rs->sr_text is set to a static string. Later on, the result is returned to the user: https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_42/servers/s… And then after that, it is free'd. This all works fine for a normal password modify operation. The problem occurs when we wrap this in an extended password modify: https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_42/servers/s… This line is where the call into ppolicy originates (with a few steps in between), and then on line 237 below we see a call to send_ldap_extended (which returns rs->sr_text to the user) that includes a pointer to rs. In cases where rs->sr_text is a static string this is fine, but where we've set it to a response from pwdCheckModule it has at this point been free'd and set to NULL before send_ldap_extended gets a chance to send it. The result is that confusingly the response from pwdCheckModule is returned for non-extended password changes, but not for extended ones. I don't have a fix for this since I'm not familiar enough with the slapd code. But I'd imagine it'd require setting a flag either in rs or op to note when free'ing of rs->sr_text is required, and then move that free call as far out as necessary (back to where rs is created in connection.c?) so that rs->sr_text is always available.

1 0

(ITS#8697) Remove refptr symbols from slapd.def
by quanah＠openldap.org 20 Jul '17

20 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Windows 10 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) When building OpenLDAP with a newer version of gcc, dlltool now exports a ton of ".refptr.FUNCTION" values out to the slapd.def file. This breaks the build process, as they aren't real functions. This is due to this change to gcc: https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00858.html Fix is simple enough, simply update our sed that we run against slapd.def: quanah@ub16:~/git/openldap/openldap-head/servers/slapd$ git diff . diff --git a/servers/slapd/Makefile.in b/servers/slapd/Makefile.in index 177ad28..0327537 100644 --- a/servers/slapd/Makefile.in +++ b/servers/slapd/Makefile.in @@ -210,7 +210,7 @@ slapd.def: libbackends.a liboverlays.a version.o dlltool --exclude-symbols main,ServiceMain@8 --export-all-symbols \ --output-def $@.tmp $$objs; echo EXPORTS > $@ - $(SED) -e 1,2d -e 's/ @ [0-9][0-9]*//' $@.tmp | sort >> $@ + $(SED) -e 1,2d -e 's/ @ [0-9][0-9]*//' -e '/\.refptr\./d' $@.tmp | sort >> $@ $(RM) $@.tmp symdummy.c: slapd.def

1 0

(ITS#8696) deadlock with 3-way delta-MMR and syncprov-checkpoint
by ryan＠openldap.org 20 Jul '17

20 Jul '17

Full_Name: Ryan Tandy Version: 2.4.45 OS: Debian URL: Submission from: (NULL) (24.68.41.160) Submitted by: ryan This is rather similar to ITS#8429 (the deadlock is at the same location), but not enough for me to be sure it's the same. cat > slapd.conf << EOF include /path/to/core.schema include /path/to/cosine.schema serverid 1 ldap://:9001 serverid 2 ldap://:9002 serverid 3 ldap://:9003 database mdb directory db maxsize 104857600 envflags writemap index objectClass,cn,entryCSN,entryUUID,uid eq suffix dc=example,dc=com rootdn cn=root,dc=example,dc=com rootpw secret access to * by * read sizelimit unlimited syncrepl rid=1 provider="ldap://:9001" searchbase="dc=example,dc=com" type=refreshAndPersist retry="10 +" bindmethod=simple binddn="cn=root,dc=example,dc=com" credentials="secret" syncdata=accesslog logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncrepl rid=2 provider="ldap://:9002" searchbase="dc=example,dc=com" type=refreshAndPersist retry="10 +" bindmethod=simple binddn="cn=root,dc=example,dc=com" credentials="secret" syncdata=accesslog logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncrepl rid=3 provider="ldap://:9003" searchbase="dc=example,dc=com" type=refreshAndPersist retry="10 +" bindmethod=simple binddn="cn=root,dc=example,dc=com" credentials="secret" syncdata=accesslog logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" mirrormode on overlay syncprov syncprov-checkpoint 10 1 syncprov-reloadhint TRUE overlay accesslog logdb cn=accesslog logops writes logsuccess true logpurge 07+00:00 01+00:00 database mdb directory accesslog maxsize 104857600 envflags writemap index entryCSN,objectClass,reqEnd,reqResult,reqStart eq suffix cn=accesslog access to * by * read sizelimit unlimited overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE EOF cat > data.ldif << EOF dn: dc=example,dc=com objectClass: domain dn: uid=u0,dc=example,dc=com objectclass: account dn: cn=g0,dc=example,dc=com objectClass: groupOfNames member: EOF Start up all three slapds and get them synced and settled. I also executed no-op modifications on each node to ensure every server had CSNs from all the others. cat > groupmod.ldif << EOF dn: cn=g0,dc=example,dc=com add: member member: uid=u0,dc=example,dc=com dn: cn=g0,dc=example,dc=com delete: member member: uid=u0,dc=example,dc=com EOF Execute the above modification on one node and watch the other two. After a few times, I reliably get one or both nodes hanging. If I disable syncprov-checkpoint, I cannot reproduce the hang. Backtrace from a hung node: Thread 6 (Thread 0x7f77093d0700 (LWP 28817)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x0000560c5a9af3b7 in ldap_pvt_thread_cond_wait (cond=0x560c5b9696c0, mutex=0x560c5b969698) at thr_posix.c:277 #2 0x0000560c5a9add6e in ldap_int_thread_pool_wrapper (xpool=0x560c5b969690) at tpool.c:683 #3 0x00007f7718a4a494 in start_thread (arg=0x7f77093d0700) at pthread_create.c:333 #4 0x00007f771878ca8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 5 (Thread 0x7f7709bd1700 (LWP 28816)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x0000560c5a9af3b7 in ldap_pvt_thread_cond_wait (cond=0x560c5b9696c0, mutex=0x560c5b969698) at thr_posix.c:277 #2 0x0000560c5a9add6e in ldap_int_thread_pool_wrapper (xpool=0x560c5b969690) at tpool.c:683 #3 0x00007f7718a4a494 in start_thread (arg=0x7f7709bd1700) at pthread_create.c:333 #4 0x00007f771878ca8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 4 (Thread 0x7f770a3d2700 (LWP 28815)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x0000560c5a9af3b7 in ldap_pvt_thread_cond_wait (cond=0x560c5b993fc8, mutex=0x560c5b993fa0) at thr_posix.c:277 #2 0x0000560c5a9ac942 in ldap_pvt_thread_rmutex_lock (rmutex=0x560c5b993f68, owner=140149249615616) at rmutex.c:129 #3 0x0000560c5a98bd4c in accesslog_op_mod (op=0x7f770a3d14e0, rs=0x7f770a3d1120) at accesslog.c:1994 #4 0x0000560c5a941763 in overlay_op_walk (op=0x7f770a3d14e0, rs=0x7f770a3d1120, which=op_modify, oi=0x560c5b992a00, on=0x560c5b993d20) at backover.c:661 #5 0x0000560c5a941a50 in over_op_func (op=0x7f770a3d14e0, rs=0x7f770a3d1120, which=op_modify) at backover.c:730 #6 0x0000560c5a941b84 in over_op_modify (op=0x7f770a3d14e0, rs=0x7f770a3d1120) at backover.c:769 #7 0x0000560c5a92ef07 in syncrepl_message_to_op (si=0x560c5b992580, op=0x7f770a3d14e0, msg=0x7f76f4103bd0) at syncrepl.c:2417 #8 0x0000560c5a929f7e in do_syncrep2 (op=0x7f770a3d14e0, si=0x560c5b992580) at syncrepl.c:1014 #9 0x0000560c5a92c160 in do_syncrepl (ctx=0x7f770a3d1c10, arg=0x560c5b992980) at syncrepl.c:1565 #10 0x0000560c5a8b11cd in connection_read_thread (ctx=0x7f770a3d1c10, argv=0xc) at connection.c:1296 #11 0x0000560c5a9ade15 in ldap_int_thread_pool_wrapper (xpool=0x560c5b969690) at tpool.c:696 #12 0x00007f7718a4a494 in start_thread (arg=0x7f770a3d2700) at pthread_create.c:333 #13 0x00007f771878ca8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 3 (Thread 0x7f770abd3700 (LWP 28814)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x0000560c5a9af3b7 in ldap_pvt_thread_cond_wait (cond=0x560c5b9696c0, mutex=0x560c5b969698) at thr_posix.c:277 #2 0x0000560c5a9add6e in ldap_int_thread_pool_wrapper (xpool=0x560c5b969690) at tpool.c:683 #3 0x00007f7718a4a494 in start_thread (arg=0x7f770abd3700) at pthread_create.c:333 #4 0x00007f771878ca8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 2 (Thread 0x7f770b3d4700 (LWP 28813)): #0 0x00007f771878d083 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 #1 0x0000560c5a8ac6b3 in slapd_daemon_task (ptr=0x560c5bd176e0) at daemon.c:2539 #2 0x00007f7718a4a494 in start_thread (arg=0x7f770b3d4700) at pthread_create.c:333 #3 0x00007f771878ca8f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 1 (Thread 0x7f7719293400 (LWP 28812)): #0 0x00007f7718a4b6cd in pthread_join (threadid=140149266401024, thread_return=0x0) at pthread_join.c:90 #1 0x0000560c5a9af2f8 in ldap_pvt_thread_join (thread=140149266401024, thread_return=0x0) at thr_posix.c:197 #2 0x0000560c5a8ad99c in slapd_daemon () at daemon.c:2932 #3 0x0000560c5a88c105 in main (argc=8, argv=0x7ffd119da7b8) at main.c:1017

1 0

(ITS#8695) _sleep is deprecated
by quanah＠openldap.org 20 Jul '17

20 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Windows 10 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) When building OpenLDAP, we find: C:/msys64/home/build/sold-master/openldap/tests/progs/slapd-read.c: In function 'do_read': C:/msys64/home/build/sold-master/openldap/tests/progs/slapd-read.c:384:11: warning: '_sleep' is deprecated [-Wdeprecated-declarations] sleep( delay ); ^~~~~ In file included from C:/msys64/home/build/sold-master/openldap/include/ac/stdlib.h:26:0, from C:/msys64/home/build/sold-master/openldap/tests/progs/slapd-read.c:24: C:/msys64/mingw64/x86_64-w64-mingw32/include/stdlib.h:613:24: note: declared here _CRTIMP void __cdecl _sleep(unsigned long _Duration) __MINGW_ATTRIB_DEPRECATED; ^~~~~~ This comes from: include/ac/unistd.h The correct function call is Sleep #ifdef _WIN32 #define sleep Sleep #endif should resolve it.

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by okuznik＠symas.com 19 Jul '17

19 Jul '17

On Tue, Jul 18, 2017 at 05:27:40PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote: > Using the behaviour above, I have been able to trigger a desync, the > script and testrun directory from it happening are available here: > ftp://ftp.openldap.org/incoming/its8444-desync.tgz It's super easy to reproduce the desync when upping MMR to 6 in that script even without memberof (no process re-nicing necessary actually). --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8694) Windows builds fail to install event information
by quanah＠symas.com 18 Jul '17

18 Jul '17

--On Tuesday, July 18, 2017 5:15 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > Running "slapd.exe install" is supposed to add the event information in > windows for startup/shutdown (1280/1281). However, this broke at some > point, and no longer provides that information. This causes the event > viewer in Windows to complain that the installation may be corrupt. Windows 10 and Windows 2012 both show this behavior. I don't have anything older than that to test against yet. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by okuznik＠symas.com 18 Jul '17

18 Jul '17

On Thu, Jun 08, 2017 at 06:36:02PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote: > A more self-contained log of the same issue, available at > ftp://ftp.openldap.org/incoming/its8444.log >=20 > (line numbers below are against current master, commit > 91f4d3a6b75e73bf4ea498e83e2e4cb4e7a320e0) >=20 > There are some things that occur in all the failures I have seen so far= : > - the server that received the operation (#1) sends the accesslog entry > with no CSN in the cookie, then another provider (#2) picks up this > message and relays it to its consumers, this one with a CSN in the > cookie > - a consumer picks up these two in short succession, in the log above, > processing of the one from #2 is finished first (they are being > processed concurrently) >=20 > Usually, once one of them gets processed, the new CSN should be noted > and the other threads should just skip it (syncrepl.c:943 and onwards). > In this one, having no CSN in the cookie seems to allow both to process > so far as to run syncrepl_message_to_op(), and one of them will then > inevitably fail to add the entry. >=20 > I don't understand yet why server #1 sends the operations without a CSN > in the cookie and (especially if I reorder the overlays to set up > memberof last), the race goes the other way around and the operation to > fail is the one from server #2. >=20 > My take on it was that in a delta-sync environment all entries would be > passed with a new CSN and that should end up in the cookie, allowing > syncrepl.c:986 to do its job. Using the behaviour above, I have been able to trigger a desync, the script and testrun directory from it happening are available here: ftp://ftp.openldap.org/incoming/its8444-desync.tgz In srv3, looking at cn=3Daccesslog, we can see that the increment by 2 ha= s been applied (and logged) twice with the same entryCSN, as: reqStart=3D20170718155142.000007Z,cn=3Daccesslog reqStart=3D20170718155142.000009Z,cn=3Daccesslog also seen in the log around those two DNs above. --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#8694) Windows builds fail to install event information
by quanah＠openldap.org 18 Jul '17

18 Jul '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Running "slapd.exe install" is supposed to add the event information in windows for startup/shutdown (1280/1281). However, this broke at some point, and no longer provides that information. This causes the event viewer in Windows to complain that the installation may be corrupt.

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