June 2022 - openldap-bugs

[Issue 9874] New: slapadd is returning garbage error data

by openldap-its＠openldap.org

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.

13 hours, 17 minutes

1
4
0 / 0

[Issue 9642] New: Adding a task to runqueue doesn't wake the main thread

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9642 Issue ID: 9642 Summary: Adding a task to runqueue doesn't wake the main thread Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a connection adds a new syncrepl stanza, that is not started until the main thread comes around to doing it. However if that thread is currently stuck in SLAP_EVENT_WAIT() and nothing else happens (like an unbind over the connection that modified the config), the task is never started. This can take a long time. No idea yet how to wake it up with/from ldap_pvt_runqueue_insert() given that sits within libldap and not really something that should be calling slap_wake_listener(). -- You are receiving this mail because: You are on the CC list for the issue.

13 hours, 52 minutes

1
4
0 / 0

[Issue 9823] New: syncprov doesn't fallback when deltasync consumer's offline beyond accesslog depth

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9823 Issue ID: 9823 Summary: syncprov doesn't fallback when deltasync consumer's offline beyond accesslog depth Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Configured w/ deltasync. When a consumer goes offline for a duration exceeding the the logpurge interval, won't fallback into syncrepl, resulting in a dsync. -- You are receiving this mail because: You are on the CC list for the issue.

13 hours, 52 minutes

1
14
0 / 0

[Issue 9468] New: slapd-ldap does anonymous bind even if rebind-as-user is set

by openldap-its＠openldap.org

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.

5 days, 9 hours

1
12
0 / 0

[Issue 9872] New: slapd-ldap(5) man page missing bold tag on authz parameter

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9872 Issue ID: 9872 Summary: slapd-ldap(5) man page missing bold tag on authz parameter Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The slapd-ldap(5) man page is missing a bold tag on the authz configuration parameter. -- You are receiving this mail because: You are on the CC list for the issue.

5 days, 9 hours

1
4
0 / 0

[Issue 9873] New: idle timeout by backends close connections

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9873 Issue ID: 9873 Summary: idle timeout by backends close connections Product: OpenLDAP Version: 2.6.2 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ettorevi(a)gmail.com Target Milestone: --- Hi, making searches through lloadd to a bunch of backends returns weird results Sometimes I get: | ldap_bind: Other (e.g., implementation specific) error (80) | additional info: connection to the remote server has been severed Others ldap_result: Can't contact LDAP server (-1) due to an idle_timeout from the backend in the middle of the search, in a non deterministic way. If I search directly on the backends everything works ldapsearch -x -Hldaps://lloadd.server 'objectClass=*' -w pwd [...] # numResponses: 9620 # numEntries: 9620 ldap_result: Can't contact LDAP server (-1) lloadd compiled standalone from 2.6.2 with: --enable-balancer=yes --enable-syslog --enable-debug --enable-slapd=no Backends are older, 2.4.49+dfsg-2ubuntu1.9 from Ubuntu 20.04 Any hints? Thank you -- You are receiving this mail because: You are on the CC list for the issue.

5 days, 14 hours

1
2
0 / 0

[Issue 9871] New: bind operations on relay entries cause slapd to segfault with rwm and ppolicy enabled

by openldap-its＠openldap.org

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.

6 days, 12 hours

1
9
0 / 0

[Issue 6166] Overlay/backend restructuring

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=6166 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- See also https://git.openldap.org/openldap/openldap/-/merge_requests/543#note_4422 for thoughts on ppolicy as well. -- You are receiving this mail because: You are on the CC list for the issue.

6 days, 15 hours

1
0
0 / 0

[Issue 7468] ppolicy and rwm/relay segfaulting

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=7468 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9871 -- You are receiving this mail because: You are on the CC list for the issue.

6 days, 18 hours

1
0
0 / 0

[Issue 7966] OpenLDAP server 2.4.40 crashes with rwm and ppolicy overlay during bind

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=7966 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 week, 4 days

1
0
0 / 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2022