- openldap-bugs - openldap.org

[Issue 9389] New: Improve the way how libldap handles interruption signal while in tls_read
by openldap-its＠openldap.org 10 Nov '20

10 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9389 Issue ID: 9389 Summary: Improve the way how libldap handles interruption signal while in tls_read Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- Description: When signal-interrupted (by any signal, i.e. SIGRTMIN+1) while in tls_read, libldap will stop the execution. It will be better to make libldap more robust because some applications may use the signals in their watchdogs (i.e. SSSD). The issue happens when client executes the function - libraries/libldap/tls2.c:1280:ldap_install_tls(LDAP *ld) (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 read server certificate A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 read server certificate request A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 read server done A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 write client certificate A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 write client key exchange A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 write change cipher spec A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 write finished A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: tls_write: want=610, written=610 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 16 03 00 00 07 0b 00 00 03 00 00 00 16 03 03 02 ................ (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0010: 06 10 00 02 02 02 00 83 00 20 ec bc 90 f5 f3 d3 ......??? ...... (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0020: 87 72 d6 a2 1e 00 d0 5d a0 64 00 00 99 9f 0b db .r.......d.M.... .... (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0230: 44 06 1c 96 00 28 ee a1 28 00 63 1f 00 49 00 34 D.......(.c..I.4 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0240: 50 63 79 78 00 11 65 de 00 5d e0 aa 00 c8 00 aa P.x.....]..[.Z. (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0250: 88 83 3e 59 00 7b 80 6b 65 a2 c3 ee 12 20 00 2c ..>Y.{.ke.... ., (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0260: 00 a1 .. (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 flush data (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: tls_read: want=5 error=Interrupted system call (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:error in SSLv3 read finished A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:error in SSLv3 read finished A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS: can't connect: . (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_free_connection 1 1 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_send_unbind (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ber_flush2: 7 bytes to sd 23 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 00 05 00 01 00 42 00 .....B. (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_write: want=7, written=7 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 00 05 00 01 01 42 00 .....B. (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_free_connection: actually freed The issue is hard to reproduce as it should be interrupted in a very precise moment. Proposal: Add a retry action somewhere inside of ldap_install_tls which will reinitiate the operation from the beginning (so it won't affect the security aspect but it will increase reliability). -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9384] Assertion failure in OpenLDAP: slapd v2.X - schema_init.c:csnNormalize23:5405
by openldap-its＠openldap.org 10 Nov '20

10 Nov '20

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

1 0

[Issue 9383] Assertion failure in OpenLDAP: slapd v2.X - schema_init.c:certificateListValidate:419
by openldap-its＠openldap.org 10 Nov '20

10 Nov '20

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

1 0

[Issue 9379] New: slapd should reject invalid listener URLs
by openldap-its＠openldap.org 10 Nov '20

10 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9379 Issue ID: 9379 Summary: slapd should reject invalid listener URLs Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: trivial Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Most common instance of invalid listener URLs is specifying an ldapi URL without URLencoding the socket pathname. Then the slashes in the pathname are treated as URL field separators, which yields a pathname quite different from what was intended. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9387] New: Support C++ Linkage
by openldap-its＠openldap.org 07 Nov '20

07 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9387 Issue ID: 9387 Summary: Support C++ Linkage Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 777 --> https://bugs.openldap.org/attachment.cgi?id=777&action=edit Add directive for supporting C++ linking The chacha8.h and module.h header files won't link properly (at least for me) with a C++ compiler/linker. I think they just need the linkage directives. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9156] latest ppolicy draft support
by openldap-its＠openldap.org 06 Nov '20

06 Nov '20

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

1 0

[Issue 8125] MMR throws away valid changes causing drift
by openldap-its＠openldap.org 06 Nov '20

06 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=8125 --- Comment #19 from Ondřej Kuzník <ondra(a)mistotebe.net> --- (In reply to Ondřej Kuzník from comment #12) > This is my understanding of the above discussion: > - deltasync consumer has just switched to full refresh (but is ahead > from this provider in some ways) > - provider sends the present list > - consumer deletes extra entries, builds a new cookie > - problem is that the new cookie is built to reflect the union of both > the local and received cookies even though we may have undone some of > the changes which we then ignore > > If that's accurate, there are some approaches that could fix it: > > 1. Simple one is to remember the actual cookie we got from the server > and refuse to delete entries with entryCSN ahead of the provided CSN > set. Problem is that we get even further from being able to replicate > from a generic RFC4533 provider. This has actually been done in ITS#9282. > 2. Instead, when present phase is initiated, we might terminate all > other sessions, adopt the complete CSN set and restart them only once > the new CSN set has been fully established. > > Also, whenever we fall back from deltasync into plain syncrepl, we > should make sure that the accesslog entries we generate from this are > never used for further replication which might be thought to be a > separate issue. Maybe the ITS#8486 work might be useful for this if > we have a way of signalling to accesslog to reset minCSN accordingly > to the new CSN set. > > The former is simpler, but the latter feels like the only one that > actually addresses these problems in full. I have some code to do this, terminate only persist sessions when we detect getting into a present refresh. Need a way to reproduce this in current master since a lot of the issues would have been fixed in ITS#9282 and might only be diverging in relayed deltasync, possibly if we're refreshing from two other providers at the same time. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5808] jldap library connect timeout doesn't work
by openldap-its＠openldap.org 04 Nov '20

04 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=5808 --- Comment #4 from klasen(a)gmx.net --- The same problem can be observed, if a non-default SocketFactory (e.g. for LDAPS connections) is used: See https://bugs.openldap.org/show_bug.cgi?id=5808 (SocketFactory does not support a connect timeout.) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9354] New: Tool for monitoring slapd status
by openldap-its＠openldap.org 02 Nov '20

02 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9354 Issue ID: 9354 Summary: Tool for monitoring slapd status Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Something we've seen in various scripts many times - this tool continuously reports operation counts from cn=Monitor and tracks contextCSN from a specified baseDN, polling at the specified interval (default 10 seconds). It tracks when contextCSN changes start and stop, and for a set of multiprovider servers, reports the lag between consumers and providers. Sample output of a screen: 2020-09-21 06:25:36 ldap://tx01 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 95 108 617710 0 0 0 600000 0 0 9 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 idle contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:03:11 contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:02:54 contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:02:19 ldap://tx02 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 105 120 2217678 0 0 0 400000 200000 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:03:09 contextCSN: 20200921004548.656746Z#000000#002#000000 idle contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:02:52 contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:02:17 ldap://uk03 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 1407 107 675570 0 3677 0 601135 14 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:02:11 contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:02:14 contextCSN: 20200921004446.224575Z#000000#003#000000 idle contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:01:33 ldap://uk04 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 98 116 2217670 0 0 0 400000 200000 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:13 contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:17 contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:01 contextCSN: 20200921004331.841460Z#000000#004#000000 idle -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9370] null-ptr dereference for unauthenticated packet in OpenLDAP slapd
by openldap-its＠openldap.org 02 Nov '20

02 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9370 --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- (In reply to Salvatore Bonaccorso from comment #3) > CVE-2020-25692 was assigned for this issue. Fyi, the official OpenLDAP Project policy is that only unintended information disclosures count as security issues, and this item does not qualify. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9370] null-ptr dereference for unauthenticated packet in OpenLDAP slapd
by openldap-its＠openldap.org 02 Nov '20

02 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9370 --- Comment #3 from Salvatore Bonaccorso <carnil(a)debian.org> --- CVE-2020-25692 was assigned for this issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9383] Assertion failure in OpenLDAP: slapd v2.X - schema_init.c:certificateListValidate:419
by openldap-its＠openldap.org 02 Nov '20

02 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9383 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- (In reply to phasip from comment #0) > A malicious packet can force OpenLDAP to fail an assertion and crash. > slapd: schema_init.c:419: int certificateListValidate(Syntax *, struct > berval *): Assertion `tag == LBER_INTEGER' failed. Note that this code was behind #ifdef LDAP_DEVEL so it is not vulnerable in any public OpenLDAP releases. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9372] New: Use POSIX semaphores by default on MacOS
by openldap-its＠openldap.org 30 Oct '20

30 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9372 Issue ID: 9372 Summary: Use POSIX semaphores by default on MacOS Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 775 --> https://bugs.openldap.org/attachment.cgi?id=775&action=edit Set POSIX semaphore as default for MacOS On Apple/MacOS, System V semaphores have a limit of 10 open robust (SEM_UNDO) semaphores at once per process, which can cause problems if a process has many open database environments/transactions open at once. Using POSIX semaphores eliminates this problems and supposedly have a little bit better performance. The attached patch (also at https://github.com/kriszyp/lmdb/commit/0971512f6a4aa5b05f99e481a6687d4802f7…) sets that as the default, and reverts back to System V semaphores with MDB_USE_ROBUST, since MacOS does not support robust POSIX locking. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9371] New: Compilation errors "unknown size" on VS/Windows
by openldap-its＠openldap.org 30 Oct '20

30 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9371 Issue ID: 9371 Summary: Compilation errors "unknown size" on VS/Windows Product: LMDB Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 774 --> https://bugs.openldap.org/attachment.cgi?id=774&action=edit Patch to fix compilation errors Compiling with VS MSBuild.exe results in multiple compilation errors like: libraries\liblmdb\mdb.c(6569): error C2036: 'void *': unknown size Patch (based on mdb.master3) at https://github.com/kriszyp/lmdb/commit/12f1bdf9be5052728694eb5fa222688f50f8… (and attached) -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9364] New: Rework encryption API
by openldap-its＠openldap.org 30 Oct '20

30 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9364 Issue ID: 9364 Summary: Rework encryption API Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Currently a single initialization vector is set at env creation time, and is used for the entire life of the DB. Ideally it should be a value uniquely generated on every write to a page. The most straightforward approach would be to use a combination of the page number and txid. Even better would be to use a keyed hash of these two values. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9377] New: Golang built-in race-detector tooling catching pointer arithmetic error on Win
by openldap-its＠openldap.org 27 Oct '20

27 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9377 Issue ID: 9377 Summary: Golang built-in race-detector tooling catching pointer arithmetic error on Win Product: LMDB Version: 0.9.25 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: AskAlexSharov(a)gmail.com Target Milestone: --- Detector of race-conditions which built into Golang tooling shows next error on Windows x86_64: mdb.c:1487:7: char buf[MSGSIZE+PADSIZE], *ptr = buf; ^ fatal error: checkptr: pointer arithmetic computed bad pointer value Link to CI where error is reproducible: https://github.com/ledgerwatch/lmdb-go/pull/8/checks?check_run_id=131269917… -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9360] New: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid
by openldap-its＠openldap.org 27 Oct '20

27 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9360 Issue ID: 9360 Summary: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: spam(a)markandruth.co.uk Target Milestone: --- I have 2 python scripts writing to a database (lmdb 0.9.26, py-lmdb 0.98) and 5-10 lua processes (with lightningmdb module which uses lmdb 0.9.22) which are long-running serving queries from the database. The database seems fine, not corrupted, and the python writes still working all the time. But periodically (perhaps 10-20% of the time), in a way I am unable to reliably reproduce, when the lua starts up every time a query is issued txn dbi_open returns "MDB_BAD_TXN: Transaction must abort, has a child, or is invalid". A direct restart of the processes does not fix this issue, however stopping lua+python and then starting again after a 5-20s wait usually fixes the issue. This has been reproduced over multiple servers but I'm at a loss as to how to debug this any further? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9370] null-ptr dereference for unauthenticated packet in OpenLDAP slapd
by openldap-its＠openldap.org 26 Oct '20

26 Oct '20

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

1 0

[Issue 9368] New: openldap-2.4.54/contrib/slapd-modules/nssov/nssov.c:950:3: warning: Suss picious use of ; at the end of 'if' statement.
by openldap-its＠openldap.org 26 Oct '20

26 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9368 Issue ID: 9368 Summary: openldap-2.4.54/contrib/slapd-modules/nssov/nssov.c:95 0:3: warning: Suss picious use of ; at the end of 'if' statement. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: dcb314(a)hotmail.com Target Milestone: --- Source code is if (ni->ni_socket >= 0); { if (close(ni->ni_socket)) Suggest drop ; -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9366] New: (async)meta does not check ldap_install_tls() return code
by openldap-its＠openldap.org 26 Oct '20

26 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9366 Issue ID: 9366 Summary: (async)meta does not check ldap_install_tls() return code Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When SLAP_STARTTLS_ASYNCHRONOUS is defined, meta and asyncmeta backends do not make sure to save the ldap_install_tls() return code so a StartTLS set up error might not be detected properly and the connection might not be closed for a while. Patch coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9376] New: Repeated deletes with DUPSORT cursor breaks
by openldap-its＠openldap.org 26 Oct '20

26 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9376 Issue ID: 9376 Summary: Repeated deletes with DUPSORT cursor breaks Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- As discussed and fixed in https://git.openldap.org/openldap/openldap/-/merge_requests/194 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

best ndis service provider in melbourne
by thebpogroup344＠gmail.com 25 Oct '20

25 Oct '20

I am a Medical Doctor in Australia and I am at this time specializing in Pediatrics. I am very loving about the work that I do. Our mission is to provide centered services with un-matched quality that support empowers permanent disable persons to make their own journey of life. As a support provider we help people with significant and permanent disability to achieve goals in their life by assisting in Community Participation, Household Tasks and many more. At Authentic Life Care, we provide home care support services to families, to assist them through challenging times in their lives. Here at Authentic Life Care, we set out our current arrangements for meeting the needs of customers who have significant and permanent disability. We maintain and improve current standards of accessibility to services for people with disabilities or those whose mobility is impaired. We will support independent travel as far as possible, with the principles of information and access elevated across the board so that clienteles with agility complications have more self-assurance in traveling. Get To Know More about us at https://authenticlifecare.com.au/

1 0

Loading freelist with large fragmented free space in LMDB
by Kris Zyp 24 Oct '20

24 Oct '20

I have noticed a performance issue with mdb_page_alloc loading the freelist while trying to find a large block when there is a significant amount of free-space that is fragmented/non-contiguous. In our application, we often have a database environment that may have a sub-database with large blocks (thousands of records around a MB), and another sub-database with many small blocks (10 of millions < 1KB). We frequently drop/delete the latter sub-database since it is an index of the former, to reindex it. However, this can leave multiple GBs of highly fragmented free space, and if we attempt to add/insert/put a record that is several MBs, mdb_page_alloc may attempt to load millions of free-page ids without finding a contiguous block. Loading large freelist seems to be an O(N^2) operation (N being size of free-list to load), since it repeatedly loads a constant size of new pages and rescans the whole cumulate IDL to search for blocks and merge new page ids (in mdb_midl_xmerge), and with very large free spaces, I've seen mdb_page_alloc take multiple minutes to complete. I think I have seen this with performing the database drop/delete as well. It seems like MDB_PARANOID may have been created to help deal with this type of issue. However, the Max_retries doesn't seem to be implemented/used by MDB_PARANOID. By adding a check to limit the retry variable to Max_retries (as seems intended), and compiling with MDB_PARANOID, I think this seems to mitigate this issue for us, and limits the free-space search so mdb_page_alloc always seems to return within a reasonable time. I was just curious if this was the intended way to deal with large free-spaces. And would it be helpful to (re?) implement the Max_retries (be glad to provide a patch) for when MDB_PARANOID is defined? Or is retry = num * 60 possibly a little bit high for a default retry setting? Or would it be preferable to improve the freelist loading to use a O(N*log N) algorithm (by possibly exponentially increasing size of blocks to load with binary tree merging) to load? Or is it better to consider this to be a pretty pathological case, and that that much free space (and record size variance) should be avoided, and that dropping/deleting such a large fragmented database should really be immediately followed by a copying the whole database environment with compaction to eliminate the excess (or all) free space? Anyway, I may be misunderstanding this issue, but my local use of MDB_PARANOID with the Max_retries fix seems like it is working fine for me (and I can certainly copy with compaction if I need to as well). Just curious if there are any suggestions otherwise, or any improvements that would be helpful to LMDB. Thanks, Kris

3 3

END
by Daniel Drinnon 23 Oct '20

23 Oct '20

END

3 2

[Issue 9373] New: Segmentation fault on ldap_simple_bind_s
by openldap-its＠openldap.org 22 Oct '20

22 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9373 Issue ID: 9373 Summary: Segmentation fault on ldap_simple_bind_s Product: OpenLDAP Version: 2.4.10 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ljin(a)microstrategy.com Target Milestone: --- Hit Faulting Signal: signal 11, Segmentation fault. when calling ldap_simple_bind_s. #0 0x00007f3e7cddec2d in poll () from /lib64/libc.so.6 #1 0x00007f3e468417d5 in ldap_result () from /usr/lib64/libldap_r-2.4.so.2 #2 0x00007f3e4684a808 in ldap_sasl_bind_s () from /usr/lib64/libldap_r-2.4.so.2 #3 0x00007f3e4684b055 in ldap_simple_bind_s () from /usr/lib64/libldap_r-2.4.so.2 This happened when there were multi-thread ldap_simple_bind_s calls. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs