June 2022 - openldap-bugs

[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 ---------------------------------------------------------------------------- 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.

1 year, 3 months

1
0
0 / 0

[Issue 9862] New: segmentation fault in ldap_simple_bind_s and openssl

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9862 Issue ID: 9862 Summary: segmentation fault in ldap_simple_bind_s and openssl Product: OpenLDAP Version: 2.4.49 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: atsoi(a)marklogic.com Target Milestone: --- We have segmentation fault when using ldap_simple_bind_s. The openldap version is 2.4.59 The openssl version is 1.0.2zd. 2021-05-09 01:11:22.021 Critical:+#5 0x00007f8f7212a038 in signalHandler(int, siginfo_t, void) () from /usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.282.b08-1.el7_9.x86_64/lib/amd64/server/libjvm.so 2021-05-09 01:11:22.021 Critical:+#6 2021-05-09 01:11:22.021 Critical:+#7 0x00007f8f78dc7f6e in BIO_set () from lib/libcrypto.so.1.0.0 2021-05-09 01:11:22.021 Critical:+#8 0x00007f8f78dc7fe2 in BIO_new () from lib/libcrypto.so.1.0.0 2021-05-09 01:11:22.021 Critical:+#9 0x00007f8f78a34574 in tlso_sb_setup () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#10 0x00007f8f787f6062 in ber_sockbuf_add_io () from lib/liblber-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#11 0x00007f8f78a31a68 in ldap_int_tls_connect.isra.1 () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#12 0x00007f8f78a32288 in ldap_int_tls_start () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#13 0x00007f8f78a0da70 in ldap_int_open_connection () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#14 0x00007f8f78a2014d in ldap_new_connection () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#15 0x00007f8f78a0d15a in ldap_open_defconn () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#16 0x00007f8f78a21568 in ldap_send_initial_request () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#17 0x00007f8f78a167a2 in ldap_sasl_bind () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#18 0x00007f8f78a16b8a in ldap_sasl_bind_s () from lib/libldap_r-2.4.so.2 2021-05-09 01:11:22.021 Critical:+#19 0x00007f8f78a172e0 in ldap_simple_bind_s () from lib/libldap_r-2.4.so.2 -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 3 months

1
4
0 / 0

[Issue 8245] slapo-unique constraints bypassed by manageDsaIt, change to relax?

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=8245 --- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 81b5ca91 by Ondřej Kuzník at 2022-06-14T21:52:18+00:00 ITS#8245 Do not try to release a NULL entry RE26 (2.6.3): • 85649edf by Ondřej Kuzník at 2022-06-23T18:34:57+00:00 ITS#8245 Do not try to release a NULL entry RE25 (2.5.13): • c8059b5d by Ondřej Kuzník at 2022-06-23T18:46:44+00:00 ITS#8245 Do not try to release a NULL entry -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 3 months

1
0
0 / 0

[Issue 8227] syncprov should use more threads

by openldap-its＠openldap.org

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

1 year, 3 months

1
0
0 / 0

[Issue 9870] New: Remove optional overlay syntax

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9870 Issue ID: 9870 Summary: Remove optional overlay syntax Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- While the module/overlay support was really young, an unreleased version of OpenLDAP supported 'optional overlays' that could fail start up without that being treated as a fatal error. This was later disabled, never documented and nowadays it can't work anyway, but the configuration option is still there in config_overlay() honouring overlay names starting with the '-' character as an alias. A patch to remove that leftover is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 3 months

1
2
0 / 0

[Issue 9869] New: LDAP over TLS not doing hostname verification in version 2.4.59

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9869 Issue ID: 9869 Summary: LDAP over TLS not doing hostname verification in version 2.4.59 Product: OpenLDAP Version: 2.4.59 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: radiatejava(a)gmail.com Target Milestone: --- My software was using openldap client 2.4.44 to talk to the LDAP server. We have shifted to 2.4.59 now to address some issues. Ever since we shifted, the new version is allowing LDAP over TLS without hostname verification. In the older 2.4.44, I always got this error if hostname did not match the CN value: return code -1 - Can't contact LDAP server) diagnostic message TLS: hostname does not match CN in peer certificate But after the lib update, no such error even if I am using LDAP server IP to do LDAP bind while LDAP server certificate has CN set as some FQDN (say test.ldap.com). Our client side code has not changed while we updated the ldap lib. For our client, we are only doing these settings: ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTDIR, lCertsDir) ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, lCert) Has there been any change in this regard? How do I enforce hostname verification now? Thanks -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 3 months

1
7
0 / 0

[Issue 8227] syncprov should use more threads

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=8227 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Yeah, just gone all the way to backlogging one consumer till we block in slapd_wait_writer() and the other one keeps receiving all messages as they are prepared, just as one would hope. Resuming the blocked consumer seems to flush everything down that connection as well. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 3 months

1
0
0 / 0

[Issue 8227] syncprov should use more threads

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=8227 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- Possibly this ticket is obsolete then. If you're satisfied that suspending/blocking one consumer doesn't interfere with other consumers' progress, we can just close this. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 3 months

1
0
0 / 0

[Issue 8227] syncprov should use more threads

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=8227 --- Comment #4 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Maybe you meant something else because I'm not seeing this, syncprov_matchops->syncprov_qresp already schedules a separate syncprov_qtask for each active persist session that has anything to send out. Those sessions each have a separate response queue, sharing a reference to the resinfo provided. And those tasks then run independent of each other sending messages (since ITS#5985 just one message at a time), reclaiming syncres and since ITS#8039 possibly resinfo as they make progress. Also verified all of this at runtime. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 3 months

1
0
0 / 0

[Issue 9580] New: Refresh vs. accesslog in delta-MPR

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9580 Issue ID: 9580 Summary: Refresh vs. accesslog in delta-MPR Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- A server consuming a plain syncrepl session (might be a delta-MMR refresh) still has to log the entries into accesslog, however that accesslog stops being capable of serving as a delta-sync source: - operation entryCSNs will be out-of-order - the changes logged will not be the intended modifications (e.g. if we fell back after a conflict, the conflicting entry will be replaced with the other version, other examples available) We need to deal with that somehow, at the very least we need to make sure the consumer will not take them at face value. We could record this in the accesslog root entry if we can detect when this starts and match it up with the final cookie, syncprov would still need some tweaks to understand it. We could mark the entries received this way and make sure delta-consumers treat them as "poison", as if they were running a plain syncrepl session themselves (not update contextCSN until that's finished, mark its own accesslog entries this way, ...). Anything like that needs guarantees that it will clean itself up once all of the real plain sessions finish otherwise we've lost delta-sync altogether. A different approach might or might not be needed for live delta-persist sessions replicating from a refreshing provider, but at least that syncprov has a way of detecting this live if it chooses to. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 3 months

1
11
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2022