- openldap-bugs - openldap.org

[Issue 5271] size limit by ip (feature request)
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

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

1 0

[Issue 10108] New: "mdb_dump -a" does not dump the main database
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10108 Issue ID: 10108 Summary: "mdb_dump -a" does not dump the main database Product: LMDB Version: 0.9.29 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: tuukka.pensala(a)gmail.com Target Milestone: --- In mdb_dump.c we have these instructions: /* -a: dump main DB and all subDBs * -s: dump only the named subDB * -n: use NOSUBDIR flag on env_open * -p: use printable characters * -f: write to file instead of stdout * -V: print version and exit * (default) dump only the main DB */ However, contrary to the description, the option -a does not dump the main DB. With argument -a "dumpit(..)" is called for the named databases, but not for the unnamed one. With the current behavior, if the data store contains subDBs and has user-added data in the main DB, there seems to be no way to dump all of it at once using mdb_dump. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10107] New: Update support page with updated procedures to request a listing.
by openldap-its＠openldap.org 03 Oct '23

03 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10107 Issue ID: 10107 Summary: Update support page with updated procedures to request a listing. Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Update the support page text at the bottom of the page on how to request a listing using the ITS system instead of email as currently is described. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9735] New: [PATCH] try hard to find free space if database cannot grow
by openldap-its＠openldap.org 01 Oct '23

01 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9735 Issue ID: 9735 Summary: [PATCH] try hard to find free space if database cannot grow Product: LMDB Version: 0.9.24 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: libor.peltan(a)nic.cz Target Milestone: --- Created attachment 851 --> https://bugs.openldap.org/attachment.cgi?id=851&action=edit Patch fixing the issue "try hard to find free space if database cannot grow" Note: - the issue is the same in version 0.9.70 (git) Situation: - the database had already grown to its limit (mapsize) in the past - overflow pages are used heavily as stored values are usually several pages long - free space got fragmented Problem: - attempt to insert new value results in MDB_MAP_FULL despite there is free space available Cause: there is a heursitic in mdb_page_alloc() that gives up searching for free space chunk if this would take too much time. This is useful when the database can still grow, as it balances performance with space usage. However, if the database can no longer grow, it prevents inserting new values. Solution: detect early on in mdb_page_alloc() if the database can grow, and if not, let it try hard to search for free space. Patch: attached -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 10102] New: DB_LOCK_DEADLOCK
by openldap-its＠openldap.org 27 Sep '23

27 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10102 Issue ID: 10102 Summary: DB_LOCK_DEADLOCK Product: OpenLDAP Version: 2.4.23 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: daniel.hy.chan(a)pccw.com Target Milestone: --- We are getting "bdb_idl_insert_key: c_del failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995)" error in Openldap debug log. We are using Openldap.2.4.23 and have configured master-slave. It seems insert error. Please kindly help. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10064] New: Add modrdn support for Cft_Misc entries
by openldap-its＠openldap.org 26 Sep '23

26 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10064 Issue ID: 10064 Summary: Add modrdn support for Cft_Misc entries 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: --- Currently in cn=config, there is some special handling to maintain overlays/dbs entries to allow list-like management. All module defined entries are marked Cft_Misc and this behaviour is not available there. It boils down to allowing the module to screen rename/renumber requests and having bconfig defer to that callback if it's defined. Use-case: policy selection rules in ITS#9343 would benefit from being managed this way rather than having to reparse a long line every time a rule is adjusted. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9471] New: Add RBAC overlay to core
by openldap-its＠openldap.org 26 Sep '23

26 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=9471 Issue ID: 9471 Summary: Add RBAC overlay to core 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: --- Symas will contribute its RBAC overlay to core The slapo-rbac overlay is an implementation of the ANSI INCITS 359 Role-Based Access Control (RBAC) Core. When instantiated, it intercepts, decodes and enforces specific RBAC policies per the Apache Fortress RBAC data formats. The overlay provides a set of extended operations. They include session create/delete, checkAccess, addActiveRole, dropActiveRole and sessionRoles. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9472] New: Add datamorph overlay to core
by openldap-its＠openldap.org 26 Sep '23

26 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=9472 Issue ID: 9472 Summary: Add datamorph overlay to core 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: --- Symas will contribute its datamorph overlay to core The datamorph overlay to slapd allows attributes with a few predefined values to be saved more space-efficiently as well as signed or unsigned integer attributes. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9473] New: Add variant overlay to core
by openldap-its＠openldap.org 26 Sep '23

26 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=9473 Issue ID: 9473 Summary: Add variant overlay to core 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: --- Symas will contribute its variant overlay to OpenLDAP core The variant overlay to slapd allows attributes/values to be shared between several entries. In some ways this is similar to slapo-collect with the exception that the source and target attributes can be different. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10087] New: slapd crashes with core dump Assertion `!LDAP_BACK_CONN_TAINTED( lc )
by openldap-its＠openldap.org 18 Sep '23

18 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10087 Issue ID: 10087 Summary: slapd crashes with core dump Assertion `!LDAP_BACK_CONN_TAINTED( lc ) Product: OpenLDAP Version: 2.5.15 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: rajko(a)albrecht.jetzt Target Milestone: --- The slapd daemon crashes every ten minutes with slapd: ../../../../../servers/slapd/back-ldap/bind.c:181: ldap_back_conn_delete: Assertion `!LDAP_BACK_CONN_TAINTED( lc )' failed. Aborted (core dumped) I searched around for multiple days but didn't find any solution to this problem. I have the same problem with 2.6.x versions. It is configured to act as caching ldap, while multiple hundred systems contact it. The error message is completely useless for sysadmins because they don't understand what this means for them (as said, asking search engines gives no answers) nor I don't know if - and if so how - I can fix this with configuration. I don't see if this message is talking about the connection to the upstream ldap server or if this is the connection from a client to the caching (and crashing) daemon. First setup was plain on a linux machine, now runnig inside docker environment so the service is restarted after the crash. This is of course not a nice solution. And it looks like the same like #4390 which is marked as "not solved". At least a description what this error messages means would be very helpful incl. how a workaround could look like (increasing timeouts, increase/decrease a socket pool or whatever). Currently the slapd is nearly useless when using it as a caching ldap with high load. Any hints? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10096] New: SIGSEGV in try_read1msg() while using referrals with AD
by openldap-its＠openldap.org 18 Sep '23

18 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10096 Issue ID: 10096 Summary: SIGSEGV in try_read1msg() while using referrals with AD Product: OpenLDAP Version: 2.6.2 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- The double free happens during a referral chasing with AD. SSSD usage Background (But I think the issue can happen even without SSSD): Referral chasing with AD and Kerberos based GSSAPI/GSS-SPNEGO authentication will never work based in the fact that AD will return domain names instead of the names of AD DC in the referral. That with with 'id_provider = ad' (SSSD setting) there is 'ldap_referrals = false' as default. For 'id_provider = ldap' we expect a generic LDAP server (not AD) which returns proper referrals with fully-qualified hostname or where is simple bind is used, either anonymous or with bind DN and password (which is expected to be the same on all involved LDAP servers and which is not the case with AD since the AD DC from a different domain won't know the given bind DN). So the issue is an unusual one, but still, as it's a crash, I think it deserves a look at. The stack trace for the issue: #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007f34182a15b3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007f3418254d46 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007f34182287f3 in __GI_abort () at abort.c:79 #4 0x00007f3418229130 in __libc_message (fmt=<optimized out>, fmt@entry=0x7f34183bb6bd "%s\n") at ../sysdeps/posix/libc_fatal.c:150 #5 0x00007f34182ab617 in malloc_printerr (str=str@entry=0x7f34183be2d0 "double free or corruption (!prev)") at malloc.c:5515 #6 0x00007f34182ad30c in _int_free (av=0x7f34183fac80 <main_arena>, p=0x560fc4b23130, have_lock=<optimized out>) at malloc.c:4458 #7 0x00007f34182af955 in __GI___libc_free (mem=<optimized out>) at malloc.c:3258 #8 0x00007f34173b6f52 in try_read1msg (result=0x7ffea107bb88, lc=0x560fc4ac20e0, all=0, msgid=-1, ld=0x560fc4a77450) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:919 #9 wait4msg (result=0x7ffea107bb88, timeout=<optimized out>, all=0, msgid=-1, ld=0x560fc4a77450) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:369 #10 ldap_result (ld=0x560fc4a77450, msgid=msgid@entry=-1, all=all@entry=0, timeout=timeout@entry=0x7ffea107bb90, result=result@entry=0x7ffea107bb88) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:120 #11 0x00007f3415b6f7be in sdap_process_result (ev=0x560fc49e2420, pvt=<optimized out>) at src/providers/ldap/sdap_async.c:233 #12 0x00007f3418433675 in tevent_common_invoke_fd_handler (fde=fde@entry=0x560fc4b07ce0, flags=1, removed=removed@entry=0x0) at ../../tevent_fd.c:142 #13 0x00007f34184373cf in epoll_event_loop (tvalp=0x7ffea107bc30, epoll_ev=0x560fc49e2700) at ../../tevent_epoll.c:737 #14 epoll_event_loop_once (ev=<optimized out>, location=<optimized out>) at ../../tevent_epoll.c:938 #15 0x00007f341842f6ab in std_event_loop_once (ev=0x560fc49e2420, location=0x7f3418575f10 "src/util/server.c:787") at ../../tevent_standard.c:110 #16 0x00007f3418431b88 in _tevent_loop_once (ev=ev@entry=0x560fc49e2420, location=location@entry=0x7f3418575f10 "src/util/server.c:787") at ../../tevent.c:825 #17 0x00007f3418431c7b in tevent_common_loop_wait (ev=0x560fc49e2420, location=0x7f3418575f10 "src/util/server.c:787") at ../../tevent.c:948 #18 0x00007f341842f71b in std_event_loop_wait (ev=0x560fc49e2420, location=0x7f3418575f10 "src/util/server.c:787") at ../../tevent_standard.c:141 #19 0x00007f3418552237 in server_loop (main_ctx=0x560fc49e2790) at src/util/server.c:787 #20 0x0000560fc371ebda in main (argc=8, argv=<optimized out>) at src/providers/data_provider_be.c:811 (gdb) frame 11 #11 0x00007f3415b6f7be in sdap_process_result (ev=0x560fc49e2420, pvt=<optimized out>) at src/providers/ldap/sdap_async.c:233 233 ret = ldap_result(sh->ldap, LDAP_RES_ANY, 0, &no_timeout, &msg); (gdb) frame 10 #10 ldap_result (ld=0x560fc4a77450, msgid=msgid@entry=-1, all=all@entry=0, timeout=timeout@entry=0x7ffea107bb90, result=result@entry=0x7ffea107bb88) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:120 120 rc = wait4msg( ld, msgid, all, timeout, result ); (gdb) frame 9 #9 wait4msg (result=0x7ffea107bb88, timeout=<optimized out>, all=0, msgid=-1, ld=0x560fc4a77450) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:369 369 rc = try_read1msg( ld, msgid, all, lc, result ); (gdb) frame 8 #8 0x00007f34173b6f52 in try_read1msg (result=0x7ffea107bb88, lc=0x560fc4ac20e0, all=0, msgid=-1, ld=0x560fc4a77450) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:919 919 ldap_return_request( ld, lr, 0 ); (gdb) frame 7 #7 0x00007f34182af955 in __GI___libc_free (mem=<optimized out>) at malloc.c:3258 3258 _int_free (ar_ptr, p, 0); (gdb) frame 6 #6 0x00007f34182ad30c in _int_free (av=0x7f34183fac80 <main_arena>, p=0x560fc4b23130, have_lock=<optimized out>) at malloc.c:4458 4458 malloc_printerr ("double free or corruption (!prev)"); (gdb) frame 8 #8 0x00007f34173b6f52 in try_read1msg (result=0x7ffea107bb88, lc=0x560fc4ac20e0, all=0, msgid=-1, ld=0x560fc4a77450) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:919 919 ldap_return_request( ld, lr, 0 ); (gdb) list 914 } 915 } 916 917 if ( lr != NULL ) { 918 if ( lr != &dummy_lr ) { 919 ldap_return_request( ld, lr, 0 ); 920 } 921 lr = NULL; 922 } 923 (gdb) p *ld $6 = {ldc = 0x560fc4b01110, ld_errno = 10, ld_error = 0x0, ld_matched = 0x0, ld_referrals = 0x0} (gdb) p *lr $8 = {lr_msgid = -995099056, lr_status = 22031, lr_refcnt = -995206016, lr_outrefcnt = 22030, lr_abandoned = 0, lr_origid = 40, lr_parentcnt = 4, lr_res_msgtype = 101, lr_res_errno = 0, lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x0, lr_conn = 0x560fc4ac20e0, lr_dn = {bv_len = 20, bv_val = 0x560fc4affe6b "\304\017V"}, lr_parent = 0x0, lr_child = 0x560fc4adb650, lr_refnext = 0x0, lr_prev = 0x0, lr_next = 0x90} Thank you! Simon -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10097] New: slapi didn't build on Windows
by openldap-its＠openldap.org 18 Sep '23

18 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10097 Issue ID: 10097 Summary: slapi didn't build on Windows Product: OpenLDAP Version: 2.6.6 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Apparently no one has ever tried to use SLAPI on Windows, since it has been broken ever since the initial commit in 2002. Fixed now in master, in 3489931553a684ab388b29dde0b8b2cf6cf63e79 and a7bd0416c80bcb954001c1b39512fb97f6c4b4ac -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10093] New: Unclear licenses in certain places
by openldap-its＠openldap.org 14 Sep '23

14 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10093 Issue ID: 10093 Summary: Unclear licenses in certain places Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: thegeorg(a)yandex-team.com Target Milestone: --- We use scancode-toolkit in order to perform automatic license analysis. At the time, this toolkit reports certain places with unclear license status. In particular, libraries/libldap/modrdn.c (lines 19 to 24) bear the following notice: ``` /* Copyright 1999, Juan C. Gomez, All rights reserved. * This software is not subject to any license of Silicon Graphics * Inc. or Purdue University. * * Redistribution and use in source and binary forms are permitted * without restriction or fee of any kind as long as this notice * is preserved. */ ``` While copyright notice is completely fine, the second part can not be recognised as any SPDX acknowledged license. Is it possible to unify the text across other parts of OpenLDAP? -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10058] New: destroying robust mutexes leads to use of an uninitialized mutex
by openldap-its＠openldap.org 27 Aug '23

27 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10058 Issue ID: 10058 Summary: destroying robust mutexes leads to use of an uninitialized mutex Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: jiri.novosad(a)gmail.com Target Milestone: --- Created attachment 966 --> https://bugs.openldap.org/attachment.cgi?id=966&action=edit an example program to reproduce the bug This is a regression introduced in https://bugs.openldap.org/show_bug.cgi?id=9278 . The issue is that mdb_env_setup_locks initializes the mutex only when it gets an exclusive fcntl file lock. But there is this possible order of operations: 1. Process A opens the DB, gets an exclusive file lock, initializes the mutex, downgrades the file lock to shared and does its thing 2. Process A closes the env: it gets an exclusive lock and destroys the mutex 3. Process B opens the DB and blocks in mdb_env_excl_lock trying to get the shared lock 4. Process A finishes closing the env, closes the file descriptor and loses the file lock 5. Process B gets the shared lock, does not initialize the mutex in mdb_env_setup_locks (because it does not have the exclusive lock) 6. Process B tries to lock the mutex, but it is not initialized, pthread_mutex_lock returns EINVAL -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 6166] Overlay/backend restructuring
by openldap-its＠openldap.org 24 Aug '23

24 Aug '23

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

1 0

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

21 Aug '23

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

1 0

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

18 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=7226 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|olcAuditlogFile At dos not |olcAuditlogFile should be |accept multiple values |single valued, but accepts | |multiple values (additional | |values ignored) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7226] olcAuditlogFile At dos not accept multiple values
by openldap-its＠openldap.org 18 Aug '23

18 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=7226 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CONFIRMED Resolution|FEEDBACK |--- --- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Root problem of this being treated as single value, but accepting multiple values (additional values are ignored) has never been addressed, which was the original bug report here. The matching rule issue was already fixed. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10086] New: test059 does not set up valid cn=config replication
by openldap-its＠openldap.org 14 Aug '23

14 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10086 Issue ID: 10086 Summary: test059 does not set up valid cn=config replication Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For cn=config replication to be valid, the entryUUIDs must match throughout the config database. However, this is not the case when test059 executes. The entryUUID for 'dn: cn=config' differs between the two. Example: quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: cfcon.d/cn\=config.ldif entryUUID: aea058c4-bf6e-103d-9e18-4582986e9372 quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: db.1.a/cn\=config\,cn\=consumer.ldif entryUUID: ae9bd858-bf6e-103d-871e-5daccf782d22 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10090] New: regex that contains a quoted literal space or escaped space results in a parse error
by openldap-its＠openldap.org 14 Aug '23

14 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10090 Issue ID: 10090 Summary: regex that contains a quoted literal space or escaped space results in a parse error 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: --- Searching ACLs using regex expressions should allow for white space. olcAccess: to dn.subtree="dc=example,dc=com" by dn.regex="ou=Before\ After,o=example[.]com,c=US$" read by * break or olcAccess: to dn.subtree="dc=example,dc=com" by dn.regex="ou=Before[ ]After,o=example[.]com,c=US$" read by * break or any regex that contains a literal space results in a parse error. It seems like the string is broken on literal spaces irrespective of quoting. Debug output from slapd: 64cd845c.253aa590 0x7fe6f4fc9640 slapd: line 0: regular expression "ou=Before\" bad because of Trailing backslash This should also include other methods for expressing white space such as `:space:` or `\w` pattern matches. olcAccess: to dn.subtree="dc=example,dc=com" by dn.regex="ou=Before[[:space:]]After,o=example[.]com,c=US$" read by * break -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10073] New: database monitor | slapd fails to start when "database ldap" without suffix exists
by openldap-its＠openldap.org 14 Aug '23

14 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10073 Issue ID: 10073 Summary: database monitor | slapd fails to start when "database ldap" without suffix exists Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: cyusedfzfb(a)gmail.com Target Milestone: --- As requested on the mailinglist, I am filing an issue for this behaviour: Today setup the cn=Monitor backend, and after doing so, openldap failed to start with: backend_startup_one (type=monitor, suffix="cn=Monitor"): bi_db_open failed! (-1) The reason turned out to be: we had configured one of our databases ("database ldap") without a suffix. After I added a suffix, openldap started, and cn=Monitor worked as expected. It would be nice if this error message could become a little bit more specific. :-) Also: we've had the "database ldap" without a suffix in production working for many years. Perhaps cn=Monitor should be able to deal with that config as well..? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10088] New: "DN index add failed" when renaming an entry
by openldap-its＠openldap.org 08 Aug '23

08 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10088 Issue ID: 10088 Summary: "DN index add failed" when renaming an entry Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: git(a)zifbang.com Target Milestone: --- I recently updated a Docker image to the latest Debian release, which means I got a new OpenLDAP version: 2.5.13 (not sure what it was before, but definitely <=2.4.x). The old image's backend was HDB. That disappeared, so I made changes(1) to use the default MDB store. Today I found out that one of my tests is failing against this new image with a "DN index add failed" message. I traced the message down to (2), but I don't understand what is causing the message to be generated and cannot find any documentation on the function that returned the error. Basically, the test is renaming an entry to a very long name. This script shows the error: ```sh #!/usr/bin/env bash set -e function cleanup() { echo "Stopping server..." docker stop ldap-test 2>&1 1>/dev/null } trap cleanup EXIT echo "Starting server..." docker run --rm -d \ -p 1389:389 -p 1636:636 \ --name ldap-test \ ghcr.io/ldapjs/docker-test-openldap/openldap:2023-07-25 2>&1 1>/dev/null echo "Waiting for server to start..." sleep 3 echo "Renaming entry..." docker exec ldap-test \ ldapmodrdn -x -H ldapi:/// \ -D 'cn=admin,dc=planetexpress,dc=com' \ -w 'GoodNewsEveryone' \ -v -d 2 \ 'cn=Turanga Leela,ou=people,dc=planetexpress,dc=com' \ 'cn=a292979f2c86d513d48bbb9786b564b3c5228146e5ba46f404724e322544a7304a2b1049168803a5485e2d57a544c6a0d860af91330acb77e5907a9e601ad1227e80e0dc50abe963b47a004f2c90f570450d0e920d15436fdc771e3bdac0487a9735473ed3a79361d1778d7e53a7fb0e5f01f97a75ef05837d1d5496fc86968ff47fcb64' ``` What changes do I need to make in order to solve this error? I have tried applying the following ldif to my image creation, but it does not solve the problem: ```ldif dn: cn=config changetype: modify replace: oldIndexHash64 olcIndexHash64: TRUE ``` 1: https://github.com/ldapjs/docker-test-openldap/pull/3/files 2: https://git.openldap.org/openldap/openldap/-/blob/2738a32de3a324fc56effd44c… -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 8461] Unable to import LDIF from back-hdb DB to back-mdb db
by openldap-its＠openldap.org 08 Aug '23

08 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=8461 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 10088 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 8461] Unable to import LDIF from back-hdb DB to back-mdb db
by openldap-its＠openldap.org 02 Aug '23

02 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=8461 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |git(a)zifbang.com --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 10088 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 10067] New: back-meta doesn't like an empty modify
by openldap-its＠openldap.org 31 Jul '23

31 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10067 Issue ID: 10067 Summary: back-meta doesn't like an empty modify 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: --- A modify like: dn: <dn> changetype: modify sent to a back-meta DB will trigger an assert on ch_malloc(0). The code also kind of takes liberty at equating free and ch_free, which could backfire under some (extremely rare) circumstances. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs