openldap-bugs June 2023

openldap-bugs@openldap.org

2 participants
127 discussions

[Issue 9660] New: back-mdb Permission denied => Restore from backup
by openldap-its＠openldap.org 12 Jan '24

12 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=9660 Issue ID: 9660 Summary: back-mdb Permission denied => Restore from backup Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: geert.hendrickx(a)telenetgroup.be Target Milestone: --- Cosmetic issue: When an mdb database has incorrect ownership or permissions (typically after slapadd as root), back-mdb fails with: mdb_db_open: database "dc=my-domain,dc=com" cannot be opened: Permission denied (13). Restore from backup! "Permission denied" is correct, but "Restore from backup" is maybe not the most appropriate advice. ;-) -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9717] New: The RADIUSOV overlay can be incorporated into OpenLDAP
by openldap-its＠openldap.org 28 Nov '23

28 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9717 Issue ID: 9717 Summary: The RADIUSOV overlay can be incorporated into OpenLDAP Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: rdubner(a)symas.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9719] New: refreshOnly sends empty cookie when client up to date
by openldap-its＠openldap.org 16 Nov '23

16 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9719 Issue ID: 9719 Summary: refreshOnly sends empty cookie when client up to date Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Syncprov will send an empty cookie if the consumer has the same cookie as provider. To the best of my knowledge this is not in line with RFC4533 and consumers would effectively drop their cookie when the search finishes. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10065] New: slapd needs a config option for the ssf of an external security proxy using "proxy protocol v2"
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10065 Issue ID: 10065 Summary: slapd needs a config option for the ssf of an external security proxy using "proxy protocol v2" Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: sean(a)teletech.com.au Target Milestone: --- Commit 146889f introduced support for the haproxy "proxy protocol v2". A very welcome addition that allows an external security layer to be implemented. This implementation is however somewhat hobbled. Cyrus SASL uses "Security Strength Factors" or "ssf" to determine what Authentication mechanisms to offer. slapd conveys the implicit security of UNIX domain sockets to the SASL layer by specifying a non-zero ssf for these connections. This can be configured with the "olcLocalSSF" config setting. For implicit/explicit TLS connections, the "olcSecurity: tls=<n>" provides the cryptographic strength of the TLS layer to the SASL layer. For an external TLS-terminating proxy, there does not appear to be any way to inform Cyrus SASL of the presence of TLS security on these proxied connections. The outcome of this is that PLAIN and EXTERNAL authentication mechanisms are not offered to clients connecting through the secure proxy. This can be overcome by weakening the security properties of the SASL layer with the olcSaslSecProps configuration option, but this weakening will apply to all clients, not just clients connecting via the secure proxy. What is required is some way to tell slapd and it's integrated SASL layer about the presence of TLS encryption on the proxy's input. As a precaution, this might be restricted to slapd connections in the 127.0.0.0/8 [IPv6:::] address ranges. -- You are receiving this mail because: You are on the CC list for the issue.

2 29

[Issue 9902] New: Make max index DBs for back-mdb configurable
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9902 Issue ID: 9902 Summary: Make max index DBs for back-mdb configurable Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From ITS#9895: Currently there is a hardcoded limit of 128 index DBs in back-mdb. Some sites want more than this (although there's no evidence they actually use more than 128 attributes in all of their applications' search filters). For 2.5/2.6 we can simply double the constant. For 2.7 consider making it configurable. Note that increasing the number increases the size of an LMDB transaction structure, and also increases the time needed to initialize it whenever creating a transaction, so it's a bad idea to just set this to an arbitrarily large number. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9829] New: set timeouts in remoteauth overlay
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9829 Issue ID: 9829 Summary: set timeouts in remoteauth overlay Product: OpenLDAP Version: 2.5.11 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Currently, it seems there is no way to configure timeouts in the remoteauth overlay. For example, if I define a remoteauth_mapping with a file containing a list of hostnames, the first one is checked first. After "remoteauth_retry_count" * "connect_timeout" seconds, (210s on my system), remoteauth test the second server in the list. In some circumstances, it could be nice to set the connect timeout lower (or higher). -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9677] New: Create "make install-strip” target
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9677 Issue ID: 9677 Summary: Create "make install-strip” target Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- All open source make-based projects shall follow the same naming and semantics of targets, described at https://www.gnu.org/prep/standards/html_node/Standard-Targets.html . In particular “make install-strip” shall strip the binaries during the installation, while “make install” shall not strip them. In openldap currently “make install” does strip, which surprised me. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9612] New: Change index_hash64 default to on
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9612 Issue ID: 9612 Summary: Change index_hash64 default to on Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Change the default value of index_hash64. By default this means slapd won't run on a 32-bit CPU (It will continue to work on 32-bit OSes running on 64-bit CPUs). If someone needs to run slapd on a 32-bit CPU they can turn this option off. In the documentation, mark the option as deprecated for eventual removal in a future release. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9580] New: Refresh vs. accesslog in delta-MPR
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

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 13

[Issue 9341] New: Delta-sync MPR needs to be stable regardless of ordering
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9341 Issue ID: 9341 Summary: Delta-sync MPR needs to be stable regardless of ordering Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If two or more updates are spread across several providers before they have a chance to learn about the others, all replicas need to arrive at the same content regardless of the order in which they arrive. One example that is broken at the moment: - (csn a) server 1 accepts a modify - (csn b) server 2 accepts a delete on the same DN - (csn c) server 2 accepts an add on that DN again If a replica receives the actions in the order bca vs. abc, the content of the entry will be different even though the final CSN set is the same -> they will never converge. The ordering 'bac' also needs to result in eventual convergence, even if it means a refresh or replication from either provider stalling temporarily? Merge request with this test case (so far): https://git.openldap.org/openldap/openldap/-/merge_requests/145 -- You are receiving this mail because: You are on the CC list for the issue.

1 11

← Newer
1
2
3
4
5
6
7
8
9
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2023