openldap-bugs June 2022

openldap-bugs@openldap.org

1 participants
150 discussions

[Issue 9871] New: bind operations on relay entries cause slapd to segfault with rwm and ppolicy enabled
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9871 Issue ID: 9871 Summary: bind operations on relay entries cause slapd to segfault with rwm and ppolicy enabled Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: subbarao(a)computer.org Target Milestone: --- On 2.5.12, slapd crashes during bind operations on relay entries with rwm and ppolicy both enabled. A simple way to reproduce this issue is to edit tests/scripts/relay and tests/data/slapd-relay.conf as follows, and then run test030-relay. I think this issue is the same as ITS#7966 reported in 2014. --- tests/scripts/relay.orig 2022-05-04 07:57:30.000000000 -0700 +++ tests/scripts/relay 2022-06-23 17:16:42.020652093 -0700 @@ -356,6 +356,16 @@ exit 1 fi +$LDAPADD -D "$MANAGERDN" -H $URI1 -w $PASSWD <<EOF > /dev/null 2>&1 +dn: cn=ppolicy,dc=example,dc=com +objectClass: top +objectClass: device +objectClass: pwdPolicy +cn: ppolicy +pwdMinLength: 5 +pwdAttribute: userPassword +EOF + BASEDN="o=Example,c=US" echo "Changing password to database \"$BASEDN\"..." $LDAPPASSWD -H $URI1 -D "cn=Manager,$BASEDN" -w $PASSWD \ --- tests/data/slapd-relay.conf.orig 2022-05-04 07:57:30.000000000 -0700 +++ tests/data/slapd-relay.conf 2022-06-23 16:57:15.184456120 -0700 @@ -31,6 +31,8 @@ #metamod#moduleload back_meta.la #rwmmod#modulepath ../servers/slapd/overlays/ #rwmmod#moduleload rwm.la +#ppolicymod#modulepath ../servers/slapd/overlays/ +#ppolicymod#moduleload ppolicy.la ####################################################################### # database definitions @@ -46,6 +48,9 @@ #ndb#dbname db_1 #ndb#include @DATADIR@/ndb.conf +overlay ppolicy +ppolicy_default cn=ppolicy,dc=example,dc=com + database @RELAY@ suffix "o=Example,c=US" ### back-relay can automatically instantiate the rwm overlay -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9866] New: delta-sync memleak on Adds
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9866 Issue ID: 9866 Summary: delta-sync memleak on Adds Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Due to the entry->e_name massaging in back-mdb/add.c (ITS#5326) syncrepl wasn't freeing the non-normalized DN as expected after add finished. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9840] New: Fix parallel build failures
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9840 Issue ID: 9840 Summary: Fix parallel build failures Product: OpenLDAP Version: 2.5.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: yi.zhao(a)windriver.com Target Milestone: --- Created attachment 899 --> https://bugs.openldap.org/attachment.cgi?id=899&action=edit 0001-ldif-filter-fix-parallel-build-failure.patch I found there are two parallel build errors for ldif-filter and libraries: ldif-filter: ld: cannot find slapd-common.o: No such file or directory libraries: ../../build/shtool mkdir -p TOPDIR/tmp-glibc/work/cortexa15t2hf-neon-wrs-linux-gnueabi/openldap/2.5.9-r0/image/usr/lib mkdir: cannot create directory 'TOPDIR/tmp-glibc/work/cortexa15t2hf-neon-wrs-linux-gnueabi/openldap/2.5.9-r0/image/usr/lib': File exists make[1]: *** [Makefile:288: install-local] Error 1 I have attached 2 patches to fix these issues. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9824] New: getting/setting LDAP_OPT_X_SASL_ options require call to ldap_initialize
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9824 Issue ID: 9824 Summary: getting/setting LDAP_OPT_X_SASL_ options require call to ldap_initialize Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: jay.hendren(a)colorado.edu Target Milestone: --- Originally filed against python-ldap: https://github.com/python-ldap/python-ldap/issues/468 Per "man 3 ldap_get_option", some options can be set globally while others require an initialized LDAP struct: > These routines provide access to options stored either in a LDAP handle or as global options, where applicable. However, "where applicable" doesn't seem to have any further clarification. In particular, getting or setting any of the "LDAP_OPT_X_SASL_" options appears to require an initialized LDAP struct, as noted in the bug report against python-ldap, whereas most other options do not appear to share this requirement. I cannot find this fact documented anywhere. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9841] New: Build failure on musl due to conflicting declarations of ber_calloc
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9841 Issue ID: 9841 Summary: Build failure on musl due to conflicting declarations of ber_calloc Product: OpenLDAP Version: 2.5.11 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: helmut(a)subdivi.de Target Milestone: --- This is a forward of a Debian bug at https://bugs.debian.org/1008951 and a Gentoo bug at https://bugs.gentoo.org/546556. In essence, openldap #defines calloc ber_calloc and then #includes some system headers, which happen to #include <sched.h>. musl's <sched.h> happens to delcare calloc when _GNU_SOURCE is #defined. Since this is the case, musl's declaration is diverted to ber_calloc and since one parameter has a subtly different type, the declarations cause a conflict. I think this is actually two bugs. 1. musl should not declare calloc in <sched.h>. Doing so also breaks libgccjit (citation needed). 2. openldap should not #define calloc before #including system headers. Fixing either fixes the build failure. I think we should fix both. The openldap side can be fixed by reordering the #define and the relevant #include. You can find a working patch in the Debian bug above at https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1008951;filename=mu…. Does this look acceptable for inclusion into openldap? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9847] New: kqueue problem with OpenBSD
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9847 Issue ID: 9847 Summary: kqueue problem with OpenBSD Product: OpenLDAP Version: 2.6.2 Hardware: All OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stu(a)spacehopper.org Target Milestone: --- The kqueue support added to slapd for 2.5 isn't working correctly on OpenBSD. If slapd runs as a daemon, errors like these are seen: slap_client_connect: URI=ldaps://XXX Warning, ldap_start_tls failed (1) mdb_opinfo_get: err Invalid argument(22) However if slapd is run in the foreground with -d, things are ok. They are also OK if kqueue is disabled (by neutering the autoconf check). I've tested 2.5.4, 2.5.9 and 2.6.2. Here are some log excerpts: 17:23:44.692: slapd starting 17:23:44.692: daemon: added 3r listener=0x0 17:23:44.692: daemon: added 6r listener=0x100263797200 17:23:44.692: daemon: added 7r listener=0x100263785400 17:23:44.692: daemon: kqueue: listen=6 active_threads=0 tvp=zero 17:23:44.692: daemon: kqueue: listen=7 active_threads=0 tvp=zero 17:23:44.692: daemon: activity on 1 descriptor 17:23:44.692: daemon: activity on: 17:23:44.692: 17:23:44.692: daemon: kqueue: listen=6 active_threads=0 tvp=zero 17:23:44.692: daemon: kqueue: listen=7 active_threads=0 tvp=zero 17:23:44.692: >>> dnNormalize: <cn=Consumer 101> 17:23:44.692: <<< dnNormalize: <cn=consumer 101> 17:23:44.692: =>do_syncrepl rid=101 17:23:44.763: slap_client_connect: URI=ldaps://XXXXXXXXXXXXXXX Warning, ldap_start_tls failed (1) 17:23:44.781: => mdb_entry_get: ndn: "dc=XXXXXXX,dc=XXX" 17:23:44.782: => mdb_entry_get: oc: "(null)", at: "contextCSN" 17:23:44.782: mdb_opinfo_get: err Invalid argument(22) 17:23:44.782: =>do_syncrep2 rid=101 17:23:44.782: daemon: added 9r listener=0x0 17:23:44.783: daemon: activity on 1 descriptor 17:23:44.783: daemon: activity on: 17:23:44.783: 17:23:44.783: daemon: kqueue: listen=6 active_threads=0 tvp=NULL 17:23:44.783: daemon: kqueue: listen=7 active_threads=0 tvp=NULL 17:23:44.800: daemon: activity on 1 descriptor 17:23:44.800: daemon: activity on: 17:23:44.800: 9r 17:23:44.800: 17:23:44.800: daemon: read active on 9 17:23:44.800: daemon: kqueue: listen=6 active_threads=0 tvp=NULL 17:23:44.800: daemon: kqueue: listen=7 active_threads=0 tvp=NULL 17:23:44.800: connection_get(9) 17:23:44.800: connection_get(9): got connid=0 17:23:44.801: =>do_syncrepl rid=101 17:23:44.801: =>do_syncrep2 rid=101 Not sure if it's any help but looking at kdump(1) output after a run under ktrace(1) I didn't spot the immediate problem resulting in "ldap_start_tls failed (1)" however the "mdb_opinfo_get: err Invalid argument(22)" occurs after attempting to call fcntl with F_SETLK on the fd 5 which is the kqueue fd: 65304 slapd RET write 97/0x61 65304 slapd CALL poll(0x89d39cb9004,1,INFTIM) 65304 slapd STRU struct kevent [2] { ident=9, filter=EVFILT_READ, flags=0x1005<EV_ADD|EV_ENABLE>, fflags=0<>, data=0, udata=0x231a1bea } { ident=9, filter=EVFILT_EXCEPT, flags=0x1005<EV_ADD|EV_ENABLE>, fflags=0x4<>, data=0, udata=0x231a1bea } 65304 slapd STRU struct kevent { ident=9, filter=EVFILT_READ, flags=0x1005<EV_ADD|EV_ENABLE>, fflags=0<>, data=36, udata=0x231a1bea } 65304 slapd STRU struct pollfd { fd=9, events=0x3<POLLIN|POLLPRI>, revents=0x1<POLLIN> } 65304 slapd RET poll 1 65304 slapd CALL read(9,0x89ccfb103e0,0x5) 65304 slapd GIO fd 9 read 5 bytes "\^W\^C\^C\0\^_" 65304 slapd RET read 5 65304 slapd CALL read(9,0x89ccfb349c5,0x1f) 65304 slapd GIO fd 9 read 31 bytes "\M^W\M-r\M-f\M^C\M-2\M^V\M-E\^O\M-hdgq\M-"\M-o\M-&\M^[*\M-9\M^E\M-Sd\M^A2\M-QE\M-cb |\M^VI" 65304 slapd RET read 31/0x1f 65304 slapd CALL mmap(0,0x2000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) 65304 slapd RET mmap 9468564512768/0x89c926ca000 65304 slapd CALL fcntl(5,F_SETLK,0x8ef465d0) 65304 slapd RET fcntl -1 errno 22 Invalid argument 65304 slapd CALL getpid() 65304 slapd RET getpid 65304/0xff18 65304 slapd CALL sendsyslog(0x89c8ef44040,59,0<>) 65304 slapd GIO fd -1 wrote 59 bytes "<167>slapd[65304]: mdb_opinfo_get: err Invalid argument(22)" Any suggestions or requests for further information/tests would be welcome. Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 16

[Issue 9868] New: backglue and syncprov must use same pending_csn_list
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9868 Issue ID: 9868 Summary: backglue and syncprov must use same pending_csn_list Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When replication is performed on a glued DB hierarchy the syncprov overlay must only be configured on the top DB. But when writes occur on a subDB their CSNs will be queued on the subDB's be_pending_csn_list. When syncprov sees these writes it will try to graduate these CSNs from the top DB's be_pending_csn_list, but never find them there. The CSN list will grow without bound. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9534] New: Persistent test043 failures
by openldap-its＠openldap.org 07 Jul '22

07 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9534 Issue ID: 9534 Summary: Persistent test043 failures Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- In testing current RE25 as of 4/23/2021 (73b2769d05529a7d474661023f2c4f3a931417b2) test043 is sporadically failing. Examining the testrun log, it appears replication never even initiated. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9874] New: slapadd is returning garbage error data
by openldap-its＠openldap.org 05 Jul '22

05 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9874 Issue ID: 9874 Summary: slapadd is returning garbage error data Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When slapadd encounters an error, instead of returning that error it is returning garbage text. Example: slapadd: could not add entry dn="olcDatabase={1}mdb,cn=config" (line=1119): #]I Note the: "#]I" If run with -d -1, we see the actual error is: mdb_db_init: Initializing mdb database olcDbDirectory: value #0: invalid path: No such file or directory slapadd: could not add entry dn="olcDatabase={1}mdb,cn=config" (line=1119): olcDbDirectory: value #0: invalid path: No such file or directory slapadd shutdown: initiated -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9468] New: slapd-ldap does anonymous bind even if rebind-as-user is set
by openldap-its＠openldap.org 30 Jun '22

30 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9468 Issue ID: 9468 Summary: slapd-ldap does anonymous bind even if rebind-as-user is set Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: tero.saarni(a)est.tech Target Milestone: --- When back-ldap retries bind operation after connection retry, it will do it as anonymous even if rebind-as-user is set to yes. Expected behavior is that (re)bind is done with user's credentials from the initial bind operation. I observed following (Warning: I might have understood details of the code incorrectly): When rebind-as-user is set and bind operation from client is processed, proxy will copy the credentials to ldapconn_t representing the remote LDAP connection. When remote LDAP connection is closed (e.g. by the proxy itself due to timeout), the bind credentials information is lost when freeing the old ldapconn_t. At this point, client still holds the connection to proxy and is unaware of the remote connection being lost. Proxy then re-establishes the connection and "synthetically" generates new bind itself, but since it does not have the credentials stored in memory anymore, it sends anonymous bind on behalf of the client. As a side effect, slapd currently crashes if remote server does not allow anonymous bind and responds with InvalidCredentials instead. The crash is due to assert(), which is handled in separate issue https://bugs.openldap.org/show_bug.cgi?id=9288 -- You are receiving this mail because: You are on the CC list for the issue.

1 12

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2022