openldap-bugs August 2025

openldap-bugs@openldap.org

1 participants
109 discussions

[Issue 9577] New: slapd -V should be deprecated
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9577 Issue ID: 9577 Summary: slapd -V should be deprecated Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Sometimes a user's (present one included) ignorance gets them in trouble unnecessarily. The -V option is an example... Normally, when one wants to determine the version of a process, they use -V, or perhaps -v. With slapd, the daemon actually continues to run, which can have negative consequences. The doc clearly states that -VV is probably what the user wants, but is counter-intutive. Who RTFM's before checking the version? -V print version info (-VV exit afterwards, -VVV print info about static overlays and backends) I propose we eliminate the option to allow slapd to continue running after displaying the version. Perhaps we eliminate the -V option entirely, or just make it work the same as -VV. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9640] New: ACL privilege for MOD_INCREMENT
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9640 Issue ID: 9640 Summary: ACL privilege for MOD_INCREMENT Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm using LDAP write operations with MOD_INCREMENT with pre-read-control for uidNumber/gidNumber generation. I'd like to limit write access to an Integer attribute "nextID" to MOD_INCREMENT, ideally even restricting the de-/increment value. (Uniqueness is achieved with slapo-unique anyway but still I'd like to avoid users messing with this attribute). IMHO the ideal solution would be a new privilege "i". Example for limiting write access to increment by one and grant read access for using read control: access to attrs=nextID val=1 by group=... =ri Example for decrementing by two without read: access to attrs=nextID val=-2 by group=... =i -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10306] New: epoll, kqueue etc. are not used when cross compiling
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10306 Issue ID: 10306 Summary: epoll, kqueue etc. are not used when cross compiling Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hi(a)alyssa.is Target Milestone: --- OpenLDAP's build system relies on running test programs to see whether epoll or kqueue are available, after checking the headers are available. When cross compiling, test programs can't be run, and even if they could, they wouldn't produce useful results because they'd be testing the build machine. Running test programs like this isn't even a great idea for native builds, because the package is still quite likely to end up running on a different machine than it was built for — think about distro packages. This means that cross-compiled OpenLDAP ends up using select, even though it could almost certainly use epoll or kqueue. The best thing to do for this sort of thing is to check at runtime whether the epoll/kqueue/whatever is available, and fall back if not, but this would probably be hard to implement in OpenLDAP. Other, easier, things that could be done to improve the situation would be: • Assume that epoll/kqueue are available if the headers are. It's very unlikely nowadays that a system with the headers won't actually have the API available. • If the AC_RUN_IFELSE checks are staying, make sure that they're all overridabel with configure flags or at least AC_CACHE_CHECK. There are also uses of AC_RUN_IFELSE for pthreads, which presumably have the same problem. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9305] New: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9305 Issue ID: 9305 Summary: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: minfrin(a)sharp.fm Target Milestone: --- When the ldap_connect_to_host() function sees a failure from getaddrinfo(), the meaningless return code -1 is returned. This makes troubleshooting difficult on a webserver, where the low level printf debugging is not practical. (gdb) step ldap_connect_to_host (ld=ld@entry=0x7fffc4002e10, sb=0x7fffc400b240, proto=1, srv=srv@entry=0x7fffc400b2f0, async=async@entry=0) at os-ip.c:543 543 { (gdb) next 546 ber_socket_t s = AC_SOCKET_INVALID; (gdb) 562 if ( srv->lud_host == NULL || *srv->lud_host == 0 ) { (gdb) 568 port = srv->lud_port; (gdb) 570 if( !port ) { (gdb) 578 switch(proto) { (gdb) 580 osip_debug( ld, (gdb) warning: Source file is more recent than executable. 71 return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); (gdb) 598 hints.ai_flags = AI_ADDRCONFIG; (gdb) 601 hints.ai_socktype = socktype; (gdb) 602 snprintf(serv, sizeof serv, "%d", port ); (gdb) 605 LDAP_MUTEX_LOCK(&ldap_int_resolv_mutex); (gdb) 607 err = getaddrinfo( host, serv, &hints, &res ); (gdb) 609 LDAP_MUTEX_UNLOCK(&ldap_int_resolv_mutex); (gdb) 611 if ( err != 0 ) { (gdb) 612 osip_debug(ld, "ldap_connect_to_host: getaddrinfo failed: %s\n", (gdb) print host $3 = <optimized out> (gdb) print serv $4 = "636\000\000\000" (gdb) next 614 return -1; (gdb) The ldap_connect_to_host() function needs to return proper error codes. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10361] New: lapo-auditlog: Add olcAuditLogNonBlocking to avoid blocking when logging to named pipes
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10361 Issue ID: 10361 Summary: lapo-auditlog: Add olcAuditLogNonBlocking to avoid blocking when logging to named pipes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: a.cudbardb(a)freeradius.org Target Milestone: --- Created attachment 1081 --> https://bugs.openldap.org/attachment.cgi?id=1081&action=edit Patch adding olcAuditlogNonBlocking and a tests for slapo-auditlog The default behaviour of fopen() when called on a named pipe which does not have any reader, is to block, until a reader opens the pipe. This in turn blocks slapo-auditlog when it attempts to write output, and prevents slapd processing requests. Depending on how critical the audit log is, it may be preferable to discard audit log output and continue processing requests if there's no reader available which olcAuditLogNonBlocking: TRUE allows. For clarity the call to fopen() is removed and replaced with open()/fdopen(), allowing us to specify O_* flags as opposed to using fopen() OR open()/fdopen() depending on whether we should block. 0666 are the base permissions used by fopen() when files are created. There were no tests for slapo-auditlog, so a small test suite that tests both the basic behaviour, and blocking/non-blocking writes. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9936] New: slapd attempting free on address which was not malloced
by openldap-its＠openldap.org 12 Dec '25

12 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9936 Issue ID: 9936 Summary: slapd attempting free on address which was not malloced Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kimjuhi96(a)snu.ac.kr Target Milestone: --- I get invalid free running this on the latest openldap from git, built with CFLAGS="-fsanitize=address" using clang 15. Seems this is similar to https://bugs.openldap.org/show_bug.cgi?id=9912. ./servers/slapd/slapd -T c -s1 -s1 Stopped reason: SIGABRT __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. gdb-peda$ bt #0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff78ca859 in __GI_abort () at abort.c:79 #2 0x00005555556eb04f in __sanitizer::Abort () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:143 #3 0x00005555556e8aac in __sanitizer::Die () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:58 #4 0x00005555556c5dda in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7fffffffbe7e, __in_chrg=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:192 #5 0x00005555556c72b8 in __asan::ReportFreeNotMalloced (addr=<optimized out>, free_stack=0x7fffffffca90) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:199 #6 0x00005555556c02ab in __interceptor_free (ptr=0x7fffffffe359) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:53 #7 0x0000555555d3efe2 in ber_memfree_x () #8 0x0000555555847d33 in ch_free () #9 0x0000555555a31178 in slap_tool_init () #10 0x0000555555a2e54d in slapcat () #11 0x000055555570901f in main () #12 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>, argc=0x5, argv=0x7fffffffdfc8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdfb8) at ../csu/libc-start.c:308 #13 0x000055555561011e in _start () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:397 gdb-peda$ -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9816] New: slapcat cordeumps during mdb subtree dump with -s
by openldap-its＠openldap.org 12 Dec '25

12 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9816 Issue ID: 9816 Summary: slapcat cordeumps during mdb subtree dump with -s Product: OpenLDAP Version: 2.5.11 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: khoffmann(a)united-internet.de Target Milestone: --- Created attachment 887 --> https://bugs.openldap.org/attachment.cgi?id=887&action=edit gdb backtrace of slapcat run When trying to use slapcat in combination with -b and -s in order to create a LDIF backup of a mdb subtree, slapd crashes with a coredump (please see the attached snippet with gdb output from a reproduced test tree). The problem was reporducible with different mdb databases / suffixes and only appears with option -s. The same dump with -H 'ldap:///ou=users,o=company,c=de??sub?' instead of -s ou=users,o=company,c=de works perfectly fine, as long as the "attrs part" is empty in the ldap-uri. Also using slapcat with -b only (for a full database dump) works fine as well. I'm aware of the fact that -s option is marked as DEPRECATED - I'm not sure if you are going to fix this bug or if you rather take the change to remove the option completely from future major versions. Please let me also know if it's expected behaviour that the -H option doesn't work whenever the attribute part isn't empty and if I should contribute to a documentation update for this edge case. Best regards, Kris -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10362] New: Normalised value confusions in replication
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10362 Issue ID: 10362 Summary: Normalised value confusions in replication 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: --- A lot of code expects a_nvals state to be consistent across modifies and multiple instances of the same attribute (with asserts to that effect), but replication doesn't seem to obey this: Add this assert into syncrepl_diff_entry()[0] : assert( ( old->a_nvals == NULL ) == ( new->a_nvals == NULL ) ); if ( old->a_nvals ) assert( ( old->a_nvals == old->a_vals ) == ( new->a_nvals == new->a_vals ) ); You'll see many tests fail this, the first of which is test043. [0]. https://git.openldap.org/openldap/openldap/-/blob/14d47146b0442df85bd949b21… -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10364] New: back-asyncmeta should process a notice-of-disconnect and close the target connection
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10364 Issue ID: 10364 Summary: back-asyncmeta should process a notice-of-disconnect and close the target connection Product: OpenLDAP Version: unspecified 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: --- At present, back-asyncmeta discards all unsolicited messages, received on the target connections. It should instead process Notice-of-Disconnection messages and close the connections on which they were received. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10363] New: Implement a target connection time-to-live in asyncmeta
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10363 Issue ID: 10363 Summary: Implement a target connection time-to-live in asyncmeta Product: OpenLDAP Version: unspecified 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: --- Implement a feature that limits the maximum time before a target connection is reset, even if it is not idle - conn-ttl. To avoid too many target connections timing out at once, a minimum reset interval per target should also be configurable. So, a configuration of: conn-ttl 5s 5s would mean connections have a 5 seconds time-to-live, but a connection should be reset no more frequently that once every 5 seconds per target. This feature was requested by a customer. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2025