openldap-bugs

openldap-bugs@openldap.org

1 participants
21108 discussions

[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 7441] cn=config filters ignore {number}
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=7441 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|IN_PROGRESS |RESOLVED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 3d94d11c by Ondřej Kuzník at 2025-12-08T18:52:59+00:00 ITS#7441 Consider both parts of an X-ORDERED value -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 6151] Update cosine.schema to RFC 4524
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=6151 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|CONFIRMED |RESOLVED Keywords|has_patch, IPR_OK | --- Comment #22 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • e6f666a1 by Ondřej Kuzník at 2025-12-04T18:26:33+00:00 ITS#6151 Update cosine.schema for RFC 4524 - adds a new substring match omitted previously (uniqueIdentifier) - removes streetAddress duplication in domain objectclass - prefers short names for MUST/MAY attributes - long definitions (for 'co', 'drink', ...) are NOT removed here - attributes/objectclasses removed by RFC 4524 are NOT removed here Chooses not to remove DESC tags removed in RFC1274 in the interests of keeping the diff small. • aa3e8f34 by Ondřej Kuzník at 2025-12-04T18:26:33+00:00 ITS#6151 Regenerate cosine.ldif -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6938] Windows IPv6 support
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

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

1 0

[Issue 6938] Windows IPv6 support
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=6938 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CONFIRMED Resolution|SUSPENDED |--- --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 90e6bfe0 by Howard Chu at 2025-12-01T16:18:46+00:00 ITS#6938 WIN32: silence warnings for redefined error codes by Howard Chu at 2025-12-01T16:18:46+00:00 ITS#6938 WIN32 IPv6: fix sockaddr_storage detection It's defined in winsock2.h. Also remove error for missing INET6_ADDRSTRLEN define, we already have it in our <ac/socket.h> if it's missing. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 7392] ACL a_dn.a_self is skipped in case of "acl_mask: to all values ..."
by openldap-its＠openldap.org 10 Dec '25

10 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=7392 --- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> --- I'm not so sure this is actually viable, allowing a self<permission> like what's requested would allow selfwrite with a blanket delete which is contrary to what our documentation says about selfwrite? Don't know how to square those two and I think there is a way to write acls that achieve the same intent by splitting them somewhat? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs