- openldap-bugs - openldap.org

[Bug 9244] New: API calls blocking after async connect
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9244 Bug ID: 9244 Summary: API calls blocking after async connect Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- Created attachment 721 --> https://bugs.openldap.org/attachment.cgi?id=721&action=edit async connect test without TLS My understanding of LDAP_OPT_CONNECT_ASYNC is that the attached program should not block. If the connection does not establish fast enough, the bind call is supposed to return LDAP_X_CONNECTING. (At least that's how I understand it, based on the original behaviour (circa 2.4.23 up to 2.4.40) as well as the bind loop in back-meta. On the other hand, the man page does "Subsequent calls to library routines will poll for completion of the connect before performing further operations" which might be interpreted as meaning they would block...) In current releases it does block, as demonstrated by strace on Linux (latency added using 'tc qdisc'): [...] connect(3, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("192.168.1.204")}, 16) = -1 EINPROGRESS (Operation now in progress) write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = 14 poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) read(3, "0\f\2\1\1a\7\n", 8) = 8 read(3, "\1\0\4\0\4\0", 6) = 6 write(2, "OK: ldap_simple_bind_returned 0 "..., 42OK: ldap_simple_bind_returned 0 (Success) ) = 42 [...] As discussed in IRC, I believe I bisected this down to commit ae6347bac, from bug 8022. The reasoning is sound, but ldap_int_open_connection does not actually return -2, only -1 or 0. The patch is simple enough, but I'm also looking at some later commits that were probably done to work around this, and might not be needed now (bug 8957, bug 8968, bug 8980). Also need to test all setups thoroughly (ldap, ldaps, STARTTLS, not to mention back-meta/asyncmeta). I also notice that LDAP_OPT_CONNECT_ASYNC is not effective unless LDAP_OPT_NETWORK_TIMEOUT is also set. It might be intentional, but the man page doesn't mention this specifically, and I don't see why it would be necessary... -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Issue 8957] Handling of TLS in async mode
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8957 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9244 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8968] Async connect mode does not work on Solaris
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8968 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9244 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8980] Async mode and TLS Non-Blocking Issue
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8980 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9244 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9229] New: Make liblutil usable by libldap
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9229 Bug ID: 9229 Summary: Make liblutil usable by libldap Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- liblutil is a static library (non-PIC) and so cannot be linked into shared objects, however we have several use cases for reusing its code in libldap. Some options: - moving more code from liblutil to libldap - just merge the whole thing? - are there components that link liblutil but _not_ libldap? - build liblutil as PIC (take a minor performance hit when linked into programs?) - build liblutil twice (liblutil.a and liblutil_pic.a) - symlink liblutil sources into libldap build dir, like libldap_r does with libldap - both of these last options require checking whether executables can call the PIC symbols safely (if some symbols are used by both library and program code) Nice-to-have for 2.5, I'd say more likely for 2.6 at this point. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9009 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |9225 Referenced Issues: https://bugs.openldap.org/show_bug.cgi?id=9225 [Issue 9225] back-mdb: Add support for PREPARE/2-phase commit -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9221] New: Move all replication consumer code into its own overlay
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9221 Bug ID: 9221 Summary: Move all replication consumer code into its own overlay Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- (In relation to a discussion about slapo-chain) <hyc> anyway, the nicer ting to fix would be in 2.5, push all of the repl consumer code into its own overlay <hyc> in that case, updateref would be processed wherever the overlay was configured <hyc> so no longer tied to the frontend <hyc> it would also make it more feasible to have multiple different consumer configs in a single DB, each with their own provider URL (and thus their own updateref) <hyc> I would think we can get rid of the update ref directive entirely, just point all writes to that consumer's provider. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 9218] New: Revist entry_release handling in slapo-pache, slapo-translucent
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9218 Bug ID: 9218 Summary: Revist entry_release handling in slapo-pache, slapo-translucent Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From a past discussion with hyc on 2.5 items: [13:57] <hyc> there's a nagging problem though, pcache's entry_release function needs to distinguish between its backend actually freeing the entry, or being a no-op [13:57] <hyc> so it can decide whether to return success or continue [13:58] <hyc> the patch to translucent sidesteps the question, by avoiding other overlays [13:58] <hyc> but we need to revisit this in 2.5 -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 9217] New: Audit all schema definitions to have official non-experimental OIDs where possible
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9217 Bug ID: 9217 Summary: Audit all schema definitions to have official non-experimental OIDs where possible Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From a past discussion with hyc on 2.5 requirements: [09:27] <hyc> we also need to audit all of these schema defs [09:27] <hyc> we're supposed to have official, non-experimental OIDs for released schema [09:28] <hyc> accesslog is still using 666, experimental arc [09:29] <hyc> I think this means we should polish up the logschema draft, Informational status, and publish it again as final -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 9216] New: Port autoca to gnutls
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9216 Bug ID: 9216 Summary: Port autoca to gnutls Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- For 2.5, support building and running the autoca overlay with GnuTLS. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Issue 10126] New: Openldap 2.5.16 Segmentation fault during start
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10126 Issue ID: 10126 Summary: Openldap 2.5.16 Segmentation fault during start Product: OpenLDAP Version: 2.5.16 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: bogdan.siara(a)gmail.com Target Milestone: --- Created attachment 987 --> https://bugs.openldap.org/attachment.cgi?id=987&action=edit gdb stacktrace Hi, I have openldap cluster with 2 nodes. Openldap is compiled in docker debian:bookworm-slim with options: ./configure --prefix=${LDAP_HOME}/openldap \ --enable-debug \ --enable-dynamic \ --enable-syslog \ --enable-ipv6 \ --enable-local \ --enable-slapd \ --enable-dynacl \ --enable-cleartext \ --enable-crypt \ --enable-spasswd \ --enable-modules \ --enable-slapi \ --enable-wrappers \ --enable-dnssrv=mod \ --enable-ldap=mod \ --enable-mdb=mod \ --enable-meta=mod \ --enable-asyncmeta=mod \ --enable-relay=mod \ --enable-overlays=mod \ --enable-argon2=yes \ --enable-balancer=mod \ --with-cyrus-sasl \ --with-threads \ --with-argon2=auto \ --without-systemd \ --with-tls=openssl make depend make make install cd contrib/slapd-modules/smbk5pwd sed -i "s|prefix=/usr/local|prefix=${LDAP_HOME}/openldap|g" Makefile sed -i "s|SSL_LIB = -lcrypto|SSL_LIB = -lnettle|g" Makefile sed -i "s|HEIMDAL_INC = -I/usr/heimdal/include|HEIMDAL_INC = \$(shell krb5-config.heimdal --cflags krb5 kadm-server)|g" Makefile sed -i "s|HEIMDAL_LIB = -L/usr/heimdal/lib -lkrb5 -lkadm5srv|HEIMDAL_LIB = \$(shell krb5-config.heimdal --libs krb5 kadm-server)|g" Makefile sed -i "s|LIBS = \$(LDAP_LIB) \$(HEIMDAL_LIB) \$(SSL_LIB)|LIBS = \$(HEIMDAL_LIB) \$(LDAP_LIB) \$(SSL_LIB)|g" Makefile make make install cd ../passwd/pbkdf2 sed -i "s|prefix=/usr/local|prefix=${LDAP_HOME}/openldap|g" Makefile sed -i "s|SSL_LIB = -lcrypto|SSL_LIB = -lnettle|g" Makefile make make install cd ../sha2 sed -i "s|prefix=/usr/local|prefix=${LDAP_HOME}/openldap|g" Makefile make make install cd ../../ppm sed -i "s|prefix=/usr/local|prefix=${LDAP_HOME}/openldap|g" Makefile make make install When I start openldap: slapd -h 'ldap://0.0.0.0:10389 ldaps://0.0.0.0:10536 ldapi://%2Fopt%2Fldap%2Fldapi' -F /opt/ldap//openldap/etc/openldap/slapd.d I get error: @(#) $OpenLDAP: slapd 2.5.16 (Nov 3 2023 07:51:03) $#012#011@f3068170494c:\/opt\/ldap\/openldap-2.5.16\/servers\/slapd /opt\/ldap\/openldap\/etc\/openldap\/slapd.d: line 1: rootdn is always granted unlimited privileges. Segmentation fault (core dumped) and in syslog: Nov 6 08:48:17 openldap-1 kernel: [44480681.935173] slapd[3775972]: segfault at 7f049da0375f ip 00007f049d75fc12 sp 00007fff24e77dd0 error 7 in libcrypto.so.3[7f049d60a000+279000] Nov 6 08:48:17 openldap-1 kernel: [44480681.935183] Code: 64 f9 ff ff eb a8 e8 ed 23 eb ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 85 ff 0f 84 a7 00 00 00 53 b8 ff ff ff ff 48 89 fb <f0> 0f c1 47 30 83 e8 01 85 c0 74 12 7e 10 5b 31 c0 31 d2 31 f6 31 Next start with gdb: ldap@openldap-1:~$ gdb --args /opt/ldap/openldap/libexec/slapd -d 0 -h ldap://0.0.0.0:10389 -F /opt/ldap//openldap/etc/openldap/slapd.d GNU gdb (Debian 13.1-3) 13.1 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /opt/ldap/openldap/libexec/slapd... (No debugging symbols found in /opt/ldap/openldap/libexec/slapd) (gdb) run Starting program: /opt/ldap/openldap/libexec/slapd -d 0 -h ldap://0.0.0.0:10389 -F /opt/ldap//openldap/etc/openldap/slapd.d [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff79bfc12 in EVP_PKEY_free () from /lib/x86_64-linux-gnu/libcrypto.so.3 (gdb) bt full #0 0x00007ffff79bfc12 in EVP_PKEY_free () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #1 0x00007ffff79fa393 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #2 0x00007ffff79fa8cd in PEM_read_bio_Parameters_ex () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #3 0x00007ffff7fa1b38 in tlso_ctx_init (lo=0x5555556fd550, lt=0x7fffffffe280, is_server=1) at tls_o.c:546 dh = 0x7ffff7c6372f <SSL_CTX_new_ex+815> bio = 0x5555558afab0 ctx = 0x55555586b760 i = <optimized out> #4 0x00007ffff7f9de08 in ldap_int_tls_init_ctx (lo=0x5555556fd550, is_server=1) at tls2.c:264 rc = 0 ti = <optimized out> lts = {lt_certfile = 0x555555773350 "/opt/ldap/openldap/etc/openldap/certs/ldap.crt", lt_keyfile = 0x555555773390 "/opt/ldap/openldap/etc/openldap/certs/ldap.key", lt_dhfile = 0x555555773470 "/opt/ldap/openldap/etc/openldap/certs/dhparam", lt_cacertfile = 0x555555773310 "/opt/ldap/openldap/etc/openldap/certs/ca.crt", lt_cacertdir = 0x0, lt_ciphersuite = 0x5555557733d0 "TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:EECDH+CHACHA20:EECDH+AESGCM:EDH+AESGCM", lt_crlfile = 0x0, lt_randfile = 0x0, lt_ecname = 0x0, lt_protocol_min = 771, lt_protocol_max = 0, lt_cacert = {bv_len = 0, bv_val = 0x0}, lt_cert = {bv_len = 0, bv_val = 0x0}, lt_key = { bv_len = 0, bv_val = 0x0}} #5 0x00005555555759e7 in main () No symbol table info available. (gdb) thread apply all bt Thread 1 (Thread 0x7ffff75ce7c0 (LWP 64) "slapd"): #0 0x00007ffff79bfc12 in EVP_PKEY_free () from /lib/x86_64-linux-gnu/libcrypto.so.3 #1 0x00007ffff79fa393 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3 #2 0x00007ffff79fa8cd in PEM_read_bio_Parameters_ex () from /lib/x86_64-linux-gnu/libcrypto.so.3 #3 0x00007ffff7fa1b38 in tlso_ctx_init (lo=0x5555556fd550, lt=0x7fffffffe280, is_server=1) at tls_o.c:546 #4 0x00007ffff7f9de08 in ldap_int_tls_init_ctx (lo=0x5555556fd550, is_server=1) at tls2.c:264 #5 0x00005555555759e7 in main () Next I rebuild openldap adding flags to configure step: ./configure CFLAGS=-g When I run slapd in new image: slapd -h 'ldap://0.0.0.0:10389 ldaps://0.0.0.0:10536 ldapi://%2Fopt%2Fldap%2Fldapi' -F /opt/ldap//openldap/etc/openldap/slapd.d all working well and I didn't get segementation fault. Can someone tell me what I'm doing wrong and how to investigate the problem? Regards BS -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10127] New: Thread Safety in LMDB with MDB_NOTLS and Readonly Cursors
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10127 Issue ID: 10127 Summary: Thread Safety in LMDB with MDB_NOTLS and Readonly Cursors Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: xiaoya2wei(a)gmail.com Target Milestone: --- Greetings LMDB Community, I am delving into the thread-safety aspects of LMDB, specifically regarding the use of readonly cursors across multiple threads. With the MDB_NOTLS flag enabled, which disables thread-local storage, my understanding is that readonly transactions may be shared between threads, provided there is proper synchronization to prevent concurrent access. Building upon this, I seek clarity on the following: Can multiple threads safely access a single readonly cursor derived from such a synchronized readonly transaction when MDB_NOTLS is enabled? Upon reviewing the LMDB source code, I noticed that cursors are tied to transactions (see mdb.c#L1335). This suggests that if threads can synchronously share a transaction, they might also share a cursor associated with it for data retrieval. I recognize my analysis might be superficial, and I'm open to corrections. Your insights on this matter would be greatly appreciated to enhance my understanding of LMDB's concurrency mechanisms. Thank you in advance for your assistance! -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 03 Nov '23

03 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8852 --- Comment #8 from Ondřej Kuzník <ondra(a)mistotebe.net> --- For comparison, using deltasync (and sortvals!) makes the consumer take a similar amount of CPU time (about +50-90 % on the provider's) to process the 10k value additions, just like Ryan noted earlier. On the other idea, no clue on whether we can somehow limit the amount of data queued up without severely impairing replication progress. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 03 Nov '23

03 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8852 --- Comment #7 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Making attr_cmp do a linear sweep for sortvals attributes (instead of the quadratic match it has to do right now) makes the consumer 7-8x slower than a provider across the board with the environment provided. I might have expected something like 3-4x but that's out of scope for this particular ITS. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8180] back-sock should not return sucess in case of error
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8180 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/657 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8677] back-sock segfaults on CONTINUE (database sock)
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8677 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/657 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=6198 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |9204 Referenced Issues: https://bugs.openldap.org/show_bug.cgi?id=9204 [Issue 9204] slapo-constraint allows anyone to apply Relax control -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8884] enabling overlay slapo-rwm makes 'entryDN' invisible
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8884 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |hyc(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8498] slapadd complains about missing attrs
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8498 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8852 --- Comment #6 from Ondřej Kuzník <ondra(a)mistotebe.net> --- attr_cmp should check the attribute is a sortval and if so, should diff without resolving to a double loop. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8498] slapadd complains about missing attrs
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8498 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- Fixed in master 2939df1a1dead2a11d1878ccd246660cda2b41a6 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8852 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- May be possible to improve diff code for standard syncrepl to improve performance on the consumer side if the attribute is sorted via sortvals, needs investigation. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8852 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Similarly, when I used AWS, it was necessary to have the consumers be set at 4k IOPS while the providers were 3k IOPS. I.e., it's generally necessary that consumers be faster than providers when processing large sequences of write updates. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8826] Contrib dsaschema module needs updating for cn=config
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8826 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8678] Slow deletes of large indexed attrributes
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8678 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |hyc(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8677] back-sock segfaults on CONTINUE (database sock)
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8677 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|overlays |backends -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8581] slapd-meta backend SSL negotiation timeout
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8581 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8581] slapd-meta backend SSL negotiation timeout
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8581 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** This issue has been marked as a duplicate of issue 8047 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8047] TIMEOUT and NETWORK_TIMEOUT don't work properly with SSL
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8047 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |louis.chanouha@univ-toulous | |e.fr --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 8581 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8524] cn=config + ditContentRule
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8524 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |--- Component|slapd |documentation Severity|development |normal --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Need to document how to correctly include this type of configuration as a part of an additional schema include. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8498] slapadd complains about missing attrs
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8498 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|quanah(a)openldap.org |hyc(a)openldap.org Target Milestone|--- |2.7.0 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Specific to using the null base, where these attributes won't exist. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8498] slapadd complains about missing attrs
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8498 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |--- Severity|normal |enhancement -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8491] slapdelete test needed
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8491 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- requires slapdelete exist first -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8182] setspec matching fails unexpectedly
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8182 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8182] setspec matching fails unexpectedly
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8182 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |SUSPENDED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- patches welcome, has usable workaound -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8182] setspec matching fails unexpectedly
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8182 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |--- -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8180] back-sock should not return sucess in case of error
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8180 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |hyc(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8178] back-sock: Timeout to avoid locking
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8178 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10121] New: cldap is not work in 2.6.0
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10121 Issue ID: 10121 Summary: cldap is not work in 2.6.0 Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: 1010881517(a)qq.com Target Milestone: --- I can't use ldapsearch to query cldap:/// on 2.6.0, but it works fine on 2.4.0. Do you have any instructions on cldap configuration?ldap and ldapi are normal. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 7981] Feature request: Crypt scheme in pwdPolicy
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=7981 --- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Rather than extending the pwdPolicy objectclass, maybe the new mechanism added in ITS#9343 could be used to override the default scheme if desided? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10111] New: dynlist crashes when using member+memberOf@groupOfNames
by openldap-its＠openldap.org 31 Oct '23

31 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10111 Issue ID: 10111 Summary: dynlist crashes when using member+memberOf@groupOfNames 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: uberthoth(a)gmail.com Target Milestone: --- slapd crashes if queried for the memberof field if dynlist has this config (which is directly from the manpage for slapo-dynlist): olcDynListAttrSet: groupOfURLs memberURL member+memberOf@groupOfNames There is an example repo with a docker-compose.yml to replicate this issue here: https://github.com/joshuacox/openldap-overlay-dynlist This may be a duplicate of this https://bugs.openldap.org/show_bug.cgi?id=10091 though I did not see a seg fault. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10072] New: Querying for transaction memory use
by openldap-its＠openldap.org 28 Oct '23

28 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10072 Issue ID: 10072 Summary: Querying for transaction memory use Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: tagwerk19.openldap(a)innerjoin.org Target Milestone: --- It would be useful to have a way to ask liblmdb how much "dirty memory" a transaction is using, up to that point. The goal is to be able to bundle writes into fewer transactions, making best use of available memory and reducing total disc writes. It is possible for an application to count the number of writes but this has only a loose relation to the *actual* number of dirty pages flagged. The target would be to write data up until the dirty memory gets to a threshold and then commit. I see that there's a: txn->mt_dirty_room and wonder if MDB_IDL_UM_MAX - txn->mt_dirty_room would give a count of that an "aware" application could make use of (an exact count? or maybe a usable and sufficient indication?) The need for this has been sharpened with the use of systemd service files that cap the memory allowed for a process, for example: MemoryHigh=512M If the process reaches this limit and continues to write data, the system uses swap. See: https://invent.kde.org/frameworks/baloo/-/merge_requests/148 Thank you for providing and supporting LMDB -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10122] New: Deletes are not replicated
by openldap-its＠openldap.org 26 Oct '23

26 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10122 Issue ID: 10122 Summary: Deletes are not replicated Product: OpenLDAP Version: 2.4.46 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kinouchi-kazuhito(a)jsdnet.co.jp Target Milestone: --- Thank you for your help. I am doing replication using syncrepl rehreshOnly mode. All of a sudden, entry deletions are no longer reflected to the consumer. Looking at the logs, nonpresent_callback is no longer printed in the consumer's logs. Further parsing the logs shows that after the last nonpresent_callback, the provider and consumer are updating the same attribute on the same entry. How should I recover? -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9959] New: Expose the lloadd connection endpoints in cn=monitor for identification
by openldap-its＠openldap.org 25 Oct '23

25 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9959 Issue ID: 9959 Summary: Expose the lloadd connection endpoints in cn=monitor for identification 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: --- ITS#9600 introduces a way to operate on lloadd connections, however it is impossible to identify which socket this actually corresponds to. While we're at it, might also expose the current bound identity there. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10085] New: test029 can't pass with SLAPD_USE_SASL is set
by openldap-its＠openldap.org 25 Oct '23

25 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10085 Issue ID: 10085 Summary: test029 can't pass with SLAPD_USE_SASL is set Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Running make test with SLAPD_USE_SASL set will fail test029. There is even a comment there that we can't support that functionality as-is when SASL binds are configured. We should probably remove that part of the test or skip it unconditionally for now. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10045] New: back-config operations abandoned while waiting in slap_pause_server() aren't committed to ldif
by openldap-its＠openldap.org 24 Oct '23

24 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10045 Issue ID: 10045 Summary: back-config operations abandoned while waiting in slap_pause_server() aren't committed to ldif Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- slap_pause_server() can take an unbounded time to process and it is possible the operation is abandoned in the meantime (e.g. the connection is lost and the loss is still noticed at this point). However the processing still goes ahead and passed onto back-ldif - where it is discarded as abandoned already so we can end up with an inconsistent view of our persistent configuration. Checking op->o_abandon again after slap_pause_server() finishes might be enough. -- You are receiving this mail because: You are on the CC list for the issue.

2 13

[Issue 10095] New: Race condition causing corruption of mutexes when closing the database
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10095 Issue ID: 10095 Summary: Race condition causing corruption of mutexes when closing the database Product: LMDB Version: 0.9.30 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: peter(a)peterzhu.ca Target Milestone: --- We're running into a race condition across multiple processes causing the corruption of mutexes when a process closes the database caused by the fix for https://bugs.openldap.org/show_bug.cgi?id=9278 (commit https://git.openldap.org/openldap/openldap/-/commit/f683ffdc81d0edb20437cb7…). Here's the interleaving of two processes (p0 and p1) that can cause this situation. p0: Opens connection to database using mdb_env_create and mdb_env_open. ...some things happen in between... p0: Begins closing the database using mdb_env_close: p0: Calls mdb_env_close0: p0: Acquires write lock on the file lock using mdb_env_excl_lock. p0: Calls pthread_mutex_destroy on the mutexes. SWITCH TO p1 p1: Begins opening the database using mdb_env_create. Then calls mdb_env_open, in mdb_env_open: p1: Calls mdb_env_setup_locks: p1: Calls mdb_env_excl_lock, but it's unable to acquire a write file lock due to p0 holding the write file lock. It waits on acquiring a read file lock. SWITCH TO p0 p0: Calls close on the file descriptor which releases the write lock. SWITCH TO p1 p1: Acquires the read file lock. p1: Does NOT call pthread_mutex_init since it did not acquire a write file lock. ...some things happen in between... p1: Try to lock the mutex using pthread_mutex_lock. This call fails with a EINVAL due to locking a destroyed mutex. I'm not sure how to actually solve this problem. We're currently mitigating this problem by reverting the commit linked above (so no mutexes get destroyed). -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 7226] olcAuditlogFile should be single valued, but accepts multiple values (additional values ignored)
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7226 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #18 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 242d1e6d by Ondřej Kuzník at 2023-08-21T12:19:16+01:00 ITS#7226 Make olcAuditlogFile SINGLE-VALUE -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9278] New: liblmdb: robust mutexes should not be unmapped
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9278 Issue ID: 9278 Summary: liblmdb: robust mutexes should not be unmapped Product: LMDB Version: unspecified Hardware: All OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: delphij(a)freebsd.org Target Milestone: --- Created attachment 736 --> https://bugs.openldap.org/attachment.cgi?id=736&action=edit A possible workaround We recently noticed that lmdb would have the memory region containing the robust mutex unmapped on mdb_env_close0(): munmap((void *)env->me_txns, (env->me_maxreaders-1)*sizeof(MDB_reader)+sizeof(MDB_txninfo)); Note that if this is the last unmap for a robust mutex, the FreeBSD implementation would garbage-collect the mutex, making it no longer visible to other processes. As the result, a second instance of the attached test.c (from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244493 with minor changes) would trigger the assertion at mdb_txn_begin() because the acquisition of the mutex would return 22 (EINVAL), because the mutex appeared to be a robust mutex, but was invalid. The attached lmdb.diff is a possible workaround for this (it would skip unmapping when setting up the robust mutex for the first time). -- You are receiving this mail because: You are on the CC list for the issue.

1 20

[Issue 10077] New: Integer overflow in util-int.c
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10077 Issue ID: 10077 Summary: Integer overflow in util-int.c Product: OpenLDAP Version: 2.6.3 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michal.pura(a)gmail.com Target Milestone: --- Created attachment 971 --> https://bugs.openldap.org/attachment.cgi?id=971&action=edit the fix proposal for ldap_pvt_gettimensec() function Hello, I found the issue with contextCNS generating process which cause that its format is invalid (minus sign in nanoseconds filed). Example: "generated new csn=20230630080704.-489933Z#000000#000#000000" The bug can introduce the minus sign in the contextCSN what could have an impact in replication process, backup restoring etc. Everywhere when the format of contextCSN is checked before processing it. According to the source code and reference documents the contextCSN nanoseconds filed should have the value from range: 000000-999999. https://www.openldap.org/faq/data/cache/1145.html The problem is in the function ldap_pvt_gettimensec() in util-int.c file. For example in line: count.QuadPart += (10 * BILLION); The value of (10 * BILLION) will be treated as 32-bit value by compilator and will cause the integer overflow. Then the random value is added to count.QuadPart what in some specific cases can produce the negative value which is returned from the function. At the end the value is passed to the function ldap_pvt_csnstr() so the contextCSN is wrongly generated (with minus sign). There is missing 'LL' qualifier, code should looks like this: count.QuadPart += (10LL * BILLION); I also suggest to change the type of _ldap_pvt_gt_offset variable from int to long long. In attachment you will find fix proposal as there are more places in the function where changes are required. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs