openldap-bugs September 2023

openldap-bugs@openldap.org

1 participants
92 discussions

[Issue 10074] New: lloadd: build broken with more recent versions of LLVM
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10074 Issue ID: 10074 Summary: lloadd: build broken with more recent versions of LLVM Product: OpenLDAP Version: 2.6.4 Hardware: All OS: FreeBSD Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: delphij(a)freebsd.org Target Milestone: --- There are two issues preventing lloadd from building with more recent versions of LLVM. These are discovered on FreeBSD but may affect other operating systems too. The first one is that ldap_pvt_thread_self is returning pthread_t (which is a pointer of struct pthread) on FreeBSD, but evthread_set_id_callback was expecting unsigned long. A possible solution would be to create a wrapper for the function, like: --- servers/lloadd/libevent_support.c.orig 2023-02-08 18:53:35 UTC +++ servers/lloadd/libevent_support.c @@ -131,6 +131,20 @@ lload_libevent_cond_timedwait( return ldap_pvt_thread_cond_wait( cond, mutex ); } +/* + * libevent2 expects the thread id has a type of unsigned long. + */ +static unsigned long +lload_libevent_thread_self(void) +{ + unsigned long retval; + static_assert(sizeof(ldap_pvt_thread_t) <= sizeof(unsigned long), + "ldap_pvt_thread_t has to be smaller or equal to unsigned long"); + + retval = (unsigned long)ldap_pvt_thread_self(); + return (retval); +} + int lload_libevent_init( void ) { @@ -152,7 +166,7 @@ lload_libevent_init( void ) evthread_set_lock_callbacks( &cbs ); evthread_set_condition_callbacks( &cond_cbs ); - evthread_set_id_callback( ldap_pvt_thread_self ); + evthread_set_id_callback( lload_libevent_thread_self ); return 0; } Or, maybe the code should just use evthread_use_pthreads() instead? (It's not very clear to me why we have the ldap_pvt_thread_self wrapper). Another issue is that module_init.c is trying to assign config_generic_wrapper to bi->bi_config: module_init.c:154:19: error: incompatible function pointer types assigning to 'BI_config *' (aka 'int (*)(struct BackendInfo *, const char *, int, int, char **)') from 'int (Backend *, const char *, int, int, char **)' (aka 'int (struct BackendDB *, const char *, int, int, char **)') [-Wincompatible-function-pointer-types] bi->bi_config = config_generic_wrapper; ^ ~~~~~~~~~~~~~~~~~~~~~~ For other backends, it's used as bi_db_config. It seems that I can set bi_config to NULL and bi_db_config to config_generic_wrapper, but it's not clear to me what the original intention was... -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10025] New: Add option to disable filtered searches for memberURL groups
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

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.

1 10

[Issue 10083] New: lload: Receiving a NoD while connection is closing already corrupts c_state
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10083 Issue ID: 10083 Summary: lload: Receiving a NoD while connection is closing already corrupts c_state 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: --- If the backend closes a connection with a NoD, two things happen: we won't be able to write to the socket and we receive the NoD message. lloadd might encounter those in either order, but handle_unsolicited() doesn't expect to be the second one to come in and happily overrides c_state, even if c_unlink() has been called by the write side already. upstream_destroy() eventually discovers the inconsistent state (LLOAD_C_CLOSING vs. LLOAD_C_DYING) and assert()s. A fix to handle_unsolicited() is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10091] New: slapd segfaults when the dynlist overlay is applied on the frontend db (with `<memberOf-ad>@<static-oc>` parameters)
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

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.

1 8

[Issue 10070] New: Allow running when /etc/resolv.conf is missing
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

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.

1 5

[Issue 10089] New: regex that does not pass `regtest()` causes the entire process to exit
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

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.

1 11

[Issue 10105] New: slapd logging fails to add newline with large search filters
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10105 Issue ID: 10105 Summary: slapd logging fails to add newline with large search filters 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: quanah(a)openldap.org Target Milestone: --- When using slapd logging rather than syslog, it fails to write a newline if the search filter is extremely long. Found this when examining the logs where the search filter has 500 users in it, in the form of: "(&(objectClass=userobject)(|(uid=abc)(uid=xyz)....)" In the slapd log, the filter gets truncated and the next log line is appended, so we end up with ...(uid=joe.hSep 27 18:21:09 hostname slapd[6373]: conn=1234 op=123 SEARCH RESULT tag=101 err=0 qtime=0.xxxx etime=0.xxx nentries=500 text= -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10057] New: slapo-homedir(5) incorrectly refers to olcArchivePath instead of olcHomedirArchivePath
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

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.

1 8

[Issue 10068] New: back-null dies on shutdown when dosearch specified
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

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.

1 3

[Issue 10094] New: When TLSv1.3 only are set TLS connection does not work
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

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.

1 14

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2023