openldap-bugs July 2022

openldap-bugs@openldap.org

1 participants
111 discussions

[Issue 9868] New: backglue and syncprov must use same pending_csn_list
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9868 Issue ID: 9868 Summary: backglue and syncprov must use same pending_csn_list Product: OpenLDAP Version: 2.5.12 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When replication is performed on a glued DB hierarchy the syncprov overlay must only be configured on the top DB. But when writes occur on a subDB their CSNs will be queued on the subDB's be_pending_csn_list. When syncprov sees these writes it will try to graduate these CSNs from the top DB's be_pending_csn_list, but never find them there. The CSN list will grow without bound. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9726] New: Admin guide and man pages need better documentation on disabling syslog
by openldap-its＠openldap.org 14 Jul '22

14 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9726 Issue ID: 9726 Summary: Admin guide and man pages need better documentation on disabling syslog Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- 2.6.0 added the new feature allowing using a logfile for all debug/loglevel messages and bypassing syslog entirely. However, there is no documentation on the new settings or examples of how to do this in the admin guide, and the man page sections on the new parameters for the logfile side do not note at when/how they enable bypassing syslog. -- You are receiving this mail because: You are on the CC list for the issue.

1 30

[Issue 9883] New: OpenLDAP version 2.4.44 for CentoOS 7.9 contains several CVEs
by openldap-its＠openldap.org 12 Jul '22

12 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9883 Issue ID: 9883 Summary: OpenLDAP version 2.4.44 for CentoOS 7.9 contains several CVEs Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: meirav.rath(a)imperva.com Target Milestone: --- Hello, My name is Meirav Rath, I'm a software developer and security champion at Imperva. As part of our effort to map security risks in our products I've been scanning our 3rd party rpms for vulnerabilities. It looks like OpenLDAP version 2.4.44 for CentOS 7.9 has the following security issues: 1. CVE-2020-36229 - https://nvd.nist.gov/vuln/detail/CVE-2020-36229 2. CVE-2019-13565 - https://nvd.nist.gov/vuln/detail/CVE-2019-13565 3. CVE-2020-36223 - https://nvd.nist.gov/vuln/detail/CVE-2020-36223 4. CVE-2020-36222 - https://nvd.nist.gov/vuln/detail/CVE-2020-36222 5. CVE-2019-13057 - https://nvd.nist.gov/vuln/detail/CVE-2019-13057 6. CVE-2021-27212 - https://nvd.nist.gov/vuln/detail/CVE-2021-27212 7. CVE-2020-36226 - https://nvd.nist.gov/vuln/detail/CVE-2020-36226 8. CVE-2020-36228 - https://nvd.nist.gov/vuln/detail/CVE-2020-36228 9. CVE-2022-29155 - https://nvd.nist.gov/vuln/detail/CVE-2022-29155 10. CVE-2020-36230 - https://nvd.nist.gov/vuln/detail/CVE-2020-36230 11. CVE-2020-36225 - https://nvd.nist.gov/vuln/detail/CVE-2020-36225 12. CVE-2020-36227 - https://nvd.nist.gov/vuln/detail/CVE-2020-36227 13. CVE-2020-36224 - https://nvd.nist.gov/vuln/detail/CVE-2020-36224 14. CVE-2020-36221 - https://nvd.nist.gov/vuln/detail/CVE-2020-36221 When can we expect an updated RPM with fixes for this issues, aimed for CentOS7.9? Thanks. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9782] New: regression test its8752 failure
by openldap-its＠openldap.org 08 Jul '22

08 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9782 Issue ID: 9782 Summary: regression test its8752 failure 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: --- If a contextCSN update (new cookie) goes from server A through server B to server C, server C will use that CSN to update entryCSN as well (which neither A nor B did). This fails the initial replication check. The issue has likely existed since deltasync was made possible, a version of this is confirmed at least in 2.4.60 onwards to current master. In principle, it is related to concerns raised in ITS#9580. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8752] MMR delta-sync deadlock using slapd.conf
by openldap-its＠openldap.org 08 Jul '22

08 Jul '22

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

1 0

[Issue 9879] New: Crash in bindconf_free
by openldap-its＠openldap.org 07 Jul '22

07 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9879 Issue ID: 9879 Summary: Crash in bindconf_free Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Slapd 2.6 (git commit 0dc9ff2594da) produes at start this output: free(): invalid pointer . The core-dump is: gdb /git/openldap bt f #0 __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:45 pid = 3060261 tid = 3060261 pd = <optimized out> val = 0 tid = <optimized out> pd = <optimized out> val = <optimized out> sc_ret = <optimized out> resultvar = <optimized out> __x = <optimized out> pid = <optimized out> resultvar = <optimized out> __arg3 = <optimized out> __arg2 = <optimized out> __arg1 = <optimized out> _a3 = <optimized out> _a2 = <optimized out> _a1 = <optimized out> #1 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at pthread_kill.c:62 No locals. #2 0x00007ff2445a91f2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 ret = <optimized out> #3 0x00007ff24459443b in __GI_abort () at abort.c:79 save_stage = 1 act = { __sigaction_handler = { sa_handler = 0x7ff244e0b590, sa_sigaction = 0x7ff244e0b590 }, sa_mask = { __val = {140678513857256, 140678514176000, 0, 4360521566522441729, 4294967295, 17981341232831397889, 140678513857472, 140678514176000, 140678513858576, 140678514161728, 37835024, 140678514167232, 5433280, 140727718055568, 140727718055515, 140678514247725} }, sa_flags = 1, sa_restorer = 0x0 } sigs = { __val = {32, 1, 140678501620784, 1, 0, 1, 140678514176000, 1, 140678501620784, 140678514176000, 140678514176880, 0, 140678514389536, 1, 140677358813185, 4294967295} } #4 0x00007ff2445e7c00 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ff2447185f4 "%s\n") at ../sysdeps/posix/libc_fatal.c:155 ap = {{ gp_offset = 24, fp_offset = 0, overflow_arg_area = 0x7ffdb9a4f2e0, reg_save_area = 0x7ffdb9a4f270 }} [31/1957] fd = <optimized out> list = <optimized out> nlist = <optimized out> cp = <optimized out> #5 0x00007ff2445fc64a in malloc_printerr (str=str@entry=0x7ff244716247 "free(): invalid pointer") at malloc.c:5543 No locals. #6 0x00007ff2445fddbc in _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:4326 size = 0 fb = <optimized out> nextchunk = <optimized out> nextsize = <optimized out> nextinuse = <optimized out> prevsize = <optimized out> bck = <optimized out> fwd = <optimized out> __PRETTY_FUNCTION__ = "_int_free" #7 0x00007ff244600821 in __GI___libc_free (mem=<optimized out>) at malloc.c:3278 ar_ptr = <optimized out> p = <optimized out> err = 13 #8 0x000000000041ab72 in bindconf_free (bc=bc@entry=0x52b970 <ldifocs+48>) at config.c:1611 No locals. #9 0x000000000046b908 in syncinfo_free (sie=0x52b940 <ldifocs>, free_all=free_all@entry=1) at syncrepl.c:6052 si_next = 0x4d8530 #10 0x0000000000429815 in backend_destroy_one (bd=0x52d8f0 <cfBackInfo+16>, dynamic=0) at backend.c:456 No locals. #11 0x000000000041651a in config_back_db_destroy (be=<optimized out>, cr=<optimized out>) at bconfig.c:7610 cfb = 0x52d8e0 <cfBackInfo> #12 0x000000000042981d in backend_destroy_one (bd=0x2445920, dynamic=1) at backend.c:459 No locals. #13 0x000000000042993a in backend_destroy () at backend.c:498 bd = <optimized out> bi = <optimized out> #14 0x000000000043e04f in slap_destroy () at init.c:258 rc = <optimized out> #15 0x000000000040a12c in main (argc=<optimized out>, argv=0x7ffdb9a4f628) at main.c:890 i = <optimized out> no_detach = <optimized out> rc = 1 urls = 0x7ffdb9a50e90 "ldap://ldap.aegee.org/ ldaps://ldap.aegee.org ldapi://%2Fvar%2Frun%2Fldapi" username = 0x7ffdb9a50e60 "openldap" groupname = 0x0 sandbox = 0x7ffdb9a50e6c "/home/openldap" pid = <optimized out> waitfds = {38815280, 0} g_argc = <optimized out> g_argv = 0x7ffdb9a4f628 configfile = 0x0 configdir = 0x7ffdb9a50e7e "/etc/openldap/" serverMode = 1 scp = <optimized out> scp_entry = <optimized out> serverNamePrefix = <synthetic pointer> l = <optimized out> slapd_pid_file_unlink = <optimized out> slapd_args_file_unlink = <optimized out> firstopt = <optimized out> Going back to commit 2cf617938 does work fine. To be precise, openldap reads certificates from its chrooted file - chr/etc/openssl/certs/ca-bundle.crt , but it had no read-access to the chr/etc/openssl/certs directory. At commit 2cf617938 does not crash at the latest 2.6 it crashes. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9534] New: Persistent test043 failures
by openldap-its＠openldap.org 07 Jul '22

07 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9534 Issue ID: 9534 Summary: Persistent test043 failures 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: --- In testing current RE25 as of 4/23/2021 (73b2769d05529a7d474661023f2c4f3a931417b2) test043 is sporadically failing. Examining the testrun log, it appears replication never even initiated. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9877] New: Session Tracking failing to log IP addresses
by openldap-its＠openldap.org 05 Jul '22

05 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9877 Issue ID: 9877 Summary: Session Tracking failing to log IP addresses Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From slapd log in master with session tracking enabled: 62c45cfe.3b59f358 0x7fa3b0aa8700 conn=1002 fd=15 ACCEPT from IP=127.0.0.1:58790 (IP=127.0.0.1:9012) 62c45cff.017af6f5 0x7fa3b0aa8700 conn=1002 op=1 [IP=[ USERNAME=cn=manager,dc=example,dc=com] modifications: 62c45cff.017b2c53 0x7fa3b0aa8700 conn=1002 op=1 [IP=[ USERNAME=cn=manager,dc=example,dc=com] MOD dn="cn=replicator,dc=example,dc=com" 62c45cff.017bb35e 0x7fa3b0aa8700 conn=1002 op=1 [IP=[ USERNAME=cn=manager,dc=example,dc=com] MOD attr=pwdLastSuccess Note the missing IP address. This works correctly in current 2.6.2 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9874] New: slapadd is returning garbage error data
by openldap-its＠openldap.org 05 Jul '22

05 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9874 Issue ID: 9874 Summary: slapadd is returning garbage error data Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When slapadd encounters an error, instead of returning that error it is returning garbage text. Example: slapadd: could not add entry dn="olcDatabase={1}mdb,cn=config" (line=1119): #]I Note the: "#]I" If run with -d -1, we see the actual error is: mdb_db_init: Initializing mdb database olcDbDirectory: value #0: invalid path: No such file or directory slapadd: could not add entry dn="olcDatabase={1}mdb,cn=config" (line=1119): olcDbDirectory: value #0: invalid path: No such file or directory slapadd shutdown: initiated -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9642] New: Adding a task to runqueue doesn't wake the main thread
by openldap-its＠openldap.org 05 Jul '22

05 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9642 Issue ID: 9642 Summary: Adding a task to runqueue doesn't wake the main thread Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a connection adds a new syncrepl stanza, that is not started until the main thread comes around to doing it. However if that thread is currently stuck in SLAP_EVENT_WAIT() and nothing else happens (like an unbind over the connection that modified the config), the task is never started. This can take a long time. No idea yet how to wake it up with/from ldap_pvt_runqueue_insert() given that sits within libldap and not really something that should be calling slap_wake_listener(). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2022