https://bugs.openldap.org/show_bug.cgi?id=10091
Issue ID: 10091
Summary: slapd segfaults when the dynlist overlay is applied on
the frontend db (with `<memberOf-ad>@<static-oc>`
parameters)
Product: OpenLDAP
Version: 2.6.6
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: philip.schildkamp(a)uni-koeln.de
Target Milestone: ---
Created attachment 974
--> https://bugs.openldap.org/attachment.cgi?id=974&action=edit
Full stacktrace of the segfault
Dear OpenLDAP Development-Team,
first of all, thank You for Your continued efforts to provide this great
software!
I've run into a segfault when trying to apply the dynlist overlay to the
frontend db. As I'm running Alpine Linux (based on musl libc), I've verified
that this segfault also occurs under GLIBC-based distros. Furthermore, I've
trimmed my config down to the bare minimum to provide a replicable setting.
This segfault only occurs when I'm trying to use the full `dynlist-attrset`
configuration (including the `+<memberOf-ad>@<static-oc>` parameters). If I
only supply the `<group-oc> <URL-ad> <member-ad>` parts of the configruation,
the segfault does not occur. And the segfault does not happen on startup, but
when connecting to the running `slapd` instance.
The version I'm running:
> @(#) $OpenLDAP: slapd 2.6.6 (Aug 7 2023 12:57:03) $
My `slapd.conf` (the same segfault occures through a `cn=config` setup):
> moduleload dynlist
>
> include /etc/openldap/schema/core.schema
>
> overlay dynlist
> dynlist-attrset labeledURIObject labeledURI member+memberOf@groupOfNames
>
> database ldif
> directory /tmp
> suffix "dc=example,dc=com"
I've attached a complete stacktrace of the segfault, which is traced back to
`dynlist.c:2057`. If I can provide any other means of debugging (e.g. a
coredump) or help in locating the root of this issue, I'd be happy to!
If this issue is known or the dynlist overlay does not support this
functionality on the frontend db, I'm sorry for the noise; but as far as I've
been able to verify, there is no mention of such a limitation within the
`slapo-dynlist` manpage (which does mention the possibility to apply the
dynlist overlay to the frontend db), nor did I find an issue regarding exactly
this error.
Again, thank You for Your efforts and
kind regards,
Philip Schildkamp
--
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=10089
Issue ID: 10089
Summary: regex that does not pass `regtest()` causes the entire
process to exit
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: gburd(a)symas.com
Target Milestone: ---
There are 6 locations in `aclparse.c` in the function `parse_acl()` that call
`regtest()` validating a regex expression before its use. Currently, when
`regtest()` finds an issue it calls `exit()` and the process must be restarted.
It seems that a better approach would be to allow the failures to be processed
by the caller where the severity might be better understood. In some (most?)
cases it's likely just fine for the process to continue after some information
about the issue is logged and resources are released properly.
https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/aclp…
--
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=10094
Issue ID: 10094
Summary: When TLSv1.3 only are set TLS connection does not work
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: nikigen68(a)gmail.com
Target Milestone: ---
The configuration with only TLSv1.3 ciphers does not work
/etc/openldap/ldap.conf
...
TLS_CIPHER_SUITE
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256
TLS_PROTOCOL_MIN 3.4
Configuration works only if at least one TLSv1.2 cipher suite is added. Then
TLSv1.3 cipher is negotiated with the server.
Is there a known issue?
--
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=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.