openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

[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 10145] New: ldap_url_parse_ext buffer overread
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10145 Issue ID: 10145 Summary: ldap_url_parse_ext buffer overread Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: joshua(a)joshua.hu Target Milestone: --- Hi there, There is an easy-to-trigger buffer overread in the function ldap_url_parse_ext in libraries/libldap/url.c: 850 url_tmp = skip_url_prefix( url_in, &enclosed, &scheme ); 851 852 if ( url_tmp == NULL ) { 853 return LDAP_URL_ERR_BADSCHEME; 854 } 855 856 assert( scheme != NULL ); 857 858 proto = ldap_pvt_url_scheme2proto( scheme ); 859 if ( proto == -1 ) { 860 return LDAP_URL_ERR_BADSCHEME; 861 } 862 863 /* make working copy of the remainder of the URL */ 864 url = LDAP_STRDUP( url_tmp ); 865 if ( url == NULL ) { 866 return LDAP_URL_ERR_MEM; 867 } 868 869 if ( enclosed ) { 870 p = &url[strlen(url)-1]; 871 872 if( *p != '>' ) { 873 LDAP_FREE( url ); 874 return LDAP_URL_ERR_BADENCLOSURE; 875 } 876 877 *p = '\0'; 878 } The function skip_url_prefix, presented with a url_in that is exactly '<ldap://', will work towards line 870, which will set: p = &url[strlen(0)-1]; This causes a one-byte buffer overread. This issue can be triggered by calling ldap_url_parse_ext with a url of exactly "<ldap://". This issue can be triggered both through the library, and slapd. ================================================================= ==1986888==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000004c2f at pc 0x7ffff7eed3c2 bp 0x7fffffffde10 sp 0x7fffffffde08 READ of size 1 at 0x602000004c2f thread T0 #0 0x7ffff7eed3c1 in ldap_url_parse_ext /home/jrogers/openldap-clean/libraries/libldap/url.c:872:7 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10124] New: olcTLSDHParamFile causes slapd general protection fault error:0 in libcrypto.so.3.0.7
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10124 Issue ID: 10124 Summary: olcTLSDHParamFile causes slapd general protection fault error:0 in libcrypto.so.3.0.7 Product: OpenLDAP Version: 2.5.16 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: r.g.van.der.kleij(a)umail.leidenuniv.nl Target Milestone: --- I am not sure this is even an openldap bug, but just in case it is I report it here. I build openldap 2.5 from source on Rocky linux 9.2. The previous build version 2.5.14 would run fine, but 2.5.16 would crash at startup with error: kernel: traps: slapd[3909] general protection fault ip:7fea2f19f2d2 sp:7fff76b17c00 error:0 in libcrypto.so.3.0.7[7fea2f0ad000+25b000] Since even in full debug nothing was logged apart from this error I started eliminating configuration items, ending up with only the config below. A fresh slapd 2.5.14 would start with only this ldif slapadded, 2.5.16 would not on the same server. Leaving out olcTLSDHParamFile would cause everything to work again. I tried regenerating a fresh 2048 bit dhparam file instead of the 4096 I was using, but no difference. openssl dhparam -out ./dhparam.pem 2048 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/scs-slapd/slapd.args olcDisallows: bind_anon olcLogLevel: stats sync olcPasswordCryptSaltFormat: $6$%.16s olcPasswordHash: {CRYPT} olcPidFile: /var/run/scs-slapd/slapd.pid olcRequires: authc olcTLSCACertificateFile: "/etc/scs/openldap/certs/ca_chain.pem" olcTLSCertificateFile: /etc/scs/openldap/certs/cert.pem olcTLSCertificateKeyFile: /etc/scs/openldap/certs/key.pem olcTLSCipherSuite: ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL :!EDH:!EXP:!SSLV2:!eNULL olcTLSCRLCheck: none olcTLSVerifyClient: allow olcTLSDHParamFile: /etc/ssl/dhparam.pem olcTLSProtocolMin: 3.3 olcToolThreads: 2 Both openssl-devel and gnutls-devel were available on the build system, but as far as I can see openssl would be preferred when available and was indeed used. (I tried both --with-tls=auto and --with-tls=openssl ) Make test would finish without issues My configure options: ./configure --prefix=$SCS_TARGET --sysconfdir=$SCS_TARGET_ETC \ --enable-debug \ --enable-slapd \ --with-systemd \ --enable-modules \ --with-tls=auto \ --with-cyrus-sasl \ --with-argon2 \ --enable-crypt \ --enable-spasswd \ --enable-rlookups \ --enable-overlays=mod \ --enable-syncprov=yes \ --enable-accesslog=mod \ --enable-backends=mod \ --enable-mdb=yes \ --enable-ndb=no \ --enable-sql=no \ --enable-wt=no \ --disable-shell The results in the configure log: TLS_LIBS='-lssl -lcrypto' WITH_TLS='yes' WITH_TLS_TYPE='openssl' -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs