openldap-bugs November 2020

openldap-bugs@openldap.org

1 participants
96 discussions

[Issue 8125] MMR throws away valid changes causing drift
by openldap-its＠openldap.org 06 Nov '20

06 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=8125 --- Comment #19 from Ondřej Kuzník <ondra(a)mistotebe.net> --- (In reply to Ondřej Kuzník from comment #12) > This is my understanding of the above discussion: > - deltasync consumer has just switched to full refresh (but is ahead > from this provider in some ways) > - provider sends the present list > - consumer deletes extra entries, builds a new cookie > - problem is that the new cookie is built to reflect the union of both > the local and received cookies even though we may have undone some of > the changes which we then ignore > > If that's accurate, there are some approaches that could fix it: > > 1. Simple one is to remember the actual cookie we got from the server > and refuse to delete entries with entryCSN ahead of the provided CSN > set. Problem is that we get even further from being able to replicate > from a generic RFC4533 provider. This has actually been done in ITS#9282. > 2. Instead, when present phase is initiated, we might terminate all > other sessions, adopt the complete CSN set and restart them only once > the new CSN set has been fully established. > > Also, whenever we fall back from deltasync into plain syncrepl, we > should make sure that the accesslog entries we generate from this are > never used for further replication which might be thought to be a > separate issue. Maybe the ITS#8486 work might be useful for this if > we have a way of signalling to accesslog to reset minCSN accordingly > to the new CSN set. > > The former is simpler, but the latter feels like the only one that > actually addresses these problems in full. I have some code to do this, terminate only persist sessions when we detect getting into a present refresh. Need a way to reproduce this in current master since a lot of the issues would have been fixed in ITS#9282 and might only be diverging in relayed deltasync, possibly if we're refreshing from two other providers at the same time. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5808] jldap library connect timeout doesn't work
by openldap-its＠openldap.org 04 Nov '20

04 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=5808 --- Comment #4 from klasen(a)gmx.net --- The same problem can be observed, if a non-default SocketFactory (e.g. for LDAPS connections) is used: See https://bugs.openldap.org/show_bug.cgi?id=5808 (SocketFactory does not support a connect timeout.) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9354] New: Tool for monitoring slapd status
by openldap-its＠openldap.org 02 Nov '20

02 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9354 Issue ID: 9354 Summary: Tool for monitoring slapd status Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Something we've seen in various scripts many times - this tool continuously reports operation counts from cn=Monitor and tracks contextCSN from a specified baseDN, polling at the specified interval (default 10 seconds). It tracks when contextCSN changes start and stop, and for a set of multiprovider servers, reports the lag between consumers and providers. Sample output of a screen: 2020-09-21 06:25:36 ldap://tx01 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 95 108 617710 0 0 0 600000 0 0 9 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 idle contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:03:11 contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:02:54 contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:02:19 ldap://tx02 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 105 120 2217678 0 0 0 400000 200000 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:03:09 contextCSN: 20200921004548.656746Z#000000#002#000000 idle contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:02:52 contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:02:17 ldap://uk03 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 1407 107 675570 0 3677 0 601135 14 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:02:11 contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:02:14 contextCSN: 20200921004446.224575Z#000000#003#000000 idle contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:01:33 ldap://uk04 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 98 116 2217670 0 0 0 400000 200000 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:13 contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:17 contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:01 contextCSN: 20200921004331.841460Z#000000#004#000000 idle -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9370] null-ptr dereference for unauthenticated packet in OpenLDAP slapd
by openldap-its＠openldap.org 02 Nov '20

02 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9370 --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- (In reply to Salvatore Bonaccorso from comment #3) > CVE-2020-25692 was assigned for this issue. Fyi, the official OpenLDAP Project policy is that only unintended information disclosures count as security issues, and this item does not qualify. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9370] null-ptr dereference for unauthenticated packet in OpenLDAP slapd
by openldap-its＠openldap.org 02 Nov '20

02 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9370 --- Comment #3 from Salvatore Bonaccorso <carnil(a)debian.org> --- CVE-2020-25692 was assigned for this issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9383] Assertion failure in OpenLDAP: slapd v2.X - schema_init.c:certificateListValidate:419
by openldap-its＠openldap.org 02 Nov '20

02 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9383 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- (In reply to phasip from comment #0) > A malicious packet can force OpenLDAP to fail an assertion and crash. > slapd: schema_init.c:419: int certificateListValidate(Syntax *, struct > berval *): Assertion `tag == LBER_INTEGER' failed. Note that this code was behind #ifdef LDAP_DEVEL so it is not vulnerable in any public OpenLDAP releases. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2020