https://bugs.openldap.org/show_bug.cgi?id=10025
Issue ID: 10025
Summary: Add option to disable filtered searches for memberURL
groups
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: subbarao(a)computer.org
Target Milestone: ---
One of the changes from 2.4 to 2.5 is that dynlist groups are now returned with
(member=memberDN) searches. This is potentially appealing, but even with the
ITS#9929 performance improvements, given the number of dynlist groups we have,
search times are significantly impacted.
We'd like to be able to cleanly disable this feature and exclude dynlist groups
from (member=memberDN) filter consideration. The only way I've found so far is
to patch the dynlist code itself. What I'm currently doing is adding a continue
statement right above this line in dynlist_search():
https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5_14/s…
That way the member searches are excluded, but dynlists otherwise work as
expected.
Here is the dynlist config we're using, just basic support for
groupOfURLs/memberURL:
overlay dynlist
dynlist-attrset groupOfURLs memberURL member
I'd like to request a configurable option to exclude dynlists from
(member=memberDN) searches.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10070
Issue ID: 10070
Summary: Allow running when /etc/resolv.conf is missing
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
A resolv.conf file might be missing, usually that means that no name services
are available (often in test environments) or in some container environments
where the resolver is assumed to run on localhost.
We should adopt the proposal discussed in
https://github.com/libevent/libevent/issues/1155#issuecomment-918826471 which
lets us honour the file if it exists but keep the libevent default, allowing to
deal with both cases, no name resolution is needed (all URIs are numeric) and
the implicit local resolver.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10057
Issue ID: 10057
Summary: slapo-homedir(5) incorrectly refers to olcArchivePath
instead of olcHomedirArchivePath
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: craig.balfour(a)gmail.com
Target Milestone: ---
The homedir overlay manual page, slapo-homedir(5), refers to attribute
olcArchivePath when the attribute is actually named olcHomedirArchivePath.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10068
Issue ID: 10068
Summary: back-null dies on shutdown when dosearch specified
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
It copies the suffix DN pointer into its entry rather than doing a ber_dupbv.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10059
Issue ID: 10059
Summary: slapo-homedir(5) could benefit from an configuration
example
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: craig.balfour(a)gmail.com
Target Milestone: ---
Created attachment 967
--> https://bugs.openldap.org/attachment.cgi?id=967&action=edit
Patch
This module could do with an example of how to configure it.
Patch attached.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10076
Issue ID: 10076
Summary: suffixmassage in back-asyncmeta does not handle empty
remote suffix correctly
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
When configuring a suffixmassage directive on an asyncmeta database,
a configuration like:
suffixmassage "dc=example,dc=com" ""
causes search requests to return error 34 "Invalid DN", because the empty
remote suffix is massaged incorrectly, adding an unnecessary ",".
The issue applies only to asyncmeta, on other proxies it functions correctly.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9944
Issue ID: 9944
Summary: Reverting an olcDbACLBind statement breaks proxied
write operations
Product: OpenLDAP
Version: 2.6.3
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: ---
On a system with olcDbIDAssertBind configured, and proxied authorizations
working correctly, an olcDbACLBind statement was added to the configuration for
lastbind support. However an incorrect identity was in place for the authzid
in the ACL bind statement which caused proxy authorization to fail. The change
was backed out (There was never any change to the olcDbIDAssertBind config
fragment) and after that, all write operations failed instead of being proxied,
with err=80. Restarting slapd fixed the issue, which indicates an underlying
problem in the cn=config db in reverting to the original working state.
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
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.
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.