- openldap-bugs - openldap.org

[Issue 9397] New: LMDB: A second process opening a file with MDB_WRITEMAP can cause the first to SIGBUS
by openldap-its＠openldap.org 12 Dec '20

12 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=9397 Issue ID: 9397 Summary: LMDB: A second process opening a file with MDB_WRITEMAP can cause the first to SIGBUS Product: LMDB Version: 0.9.26 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- Created attachment 780 --> https://bugs.openldap.org/attachment.cgi?id=780&action=edit Full reproduction of SIGBUS MDB_WRITEMAP issue (works on Linux only) The fundamental problem is that a ftruncate() on Linux that makes a file smaller will cause accesses past the new end of the file to SIGBUS (see the mmap man page). The sequence that causes a SIGBUS involves two processes. 1. The first process opens a new LMDB file with MDB_WRITEMAP. 2. The second process opens the same LMDB file with MDB_WRITEMAP and with an explicit map_size smaller than the first process's map size. * This causes an ftruncate that makes the underlying file *smaller*. 3. (Optional) The second process closes the environment and exits. 4. The first process opens a write transaction and writes a bunch of data. 5. The first process commits the transaction. This causes a memory read from the mapped memory that's now past the end of the file. On Linux, this triggers a SIGBUS. Attached is code that fully reproduces the problem on Linux. The most straightforward solution is to allow ftruncate to *reduce* the file size if it is the only reader. Another possibility is check the file size and ftruncate if necessary every time a write transaction is opened. A third possibility is to catch the SIGBUS signal. Repro note: I used clone() to create the subprocess to most straightforwardly demonstrate that the problem is not due to inherited file descriptors. The problem still manifests when the processes are completely independent. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9418] New: slapd-bconfig: potential nullptr deref
by openldap-its＠openldap.org 06 Dec '20

06 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=9418 Issue ID: 9418 Summary: slapd-bconfig: potential nullptr deref Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: danix800(a)gmail.com Target Milestone: --- Reported by clang static analyzer in servers/slapd/bconfig.c:6429 'ce->ce_parent' is potentially nullptr dereference based on the above test of 'ce->ce_parent' against null before 'access_allowed' is called, so it's better to check again. See MR!208 for a potential fix. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 6036] Crash: UUIDNormalize doesn't clear output on error
by openldap-its＠openldap.org 05 Dec '20

05 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=6036 --- Comment #5 from amez365 <fieldengineer59(a)yahoo.com> --- Infrastructure Engineer https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer Infrastructure Engineer's roles include being responsible for designing, building, implementing and maintaining the IT infrastructure using the latest technology. An IT infrastructure engineer ensures that all IT systems that support businesses of any size operate efficiently. https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer -- You are receiving this mail because: You are on the CC list for the issue.

4 3

[Issue 8528] Incorrect results on replace op for olcAccess
by openldap-its＠openldap.org 02 Dec '20

02 Dec '20

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

1 0

[Issue 9415] New: Possible use of memory after free
by openldap-its＠openldap.org 02 Dec '20

02 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=9415 Issue ID: 9415 Summary: Possible use of memory after free Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: cwe(a)skov.dk Target Milestone: --- In my code I have a construct like this: err = mdb_txn_commit(txn); if (err) { mdb_txn_abort(txn); } I run codesonar on my code and include the lmdb source in the run. Codesonar reports a possible double free for the case where mdb_midl_append_list in mdb.c line 3586 returns ENOMEM. The code following line 3586 will free the txn and return ENOMEM. This will cause my code to call mdb_txn_abort, which will access the freed memory and call free again. Please ask if more details are needed. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9401] New: Fix ldap_install_tls function name
by openldap-its＠openldap.org 30 Nov '20

30 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9401 Issue ID: 9401 Summary: Fix ldap_install_tls function name Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The ldap_install_tls function is really an internal only method for slapd. It should be renamed accordingly to ldap_int_install_tls to reflect this fact, and the documentation updated accordingly. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8528] Incorrect results on replace op for olcAccess
by openldap-its＠openldap.org 27 Nov '20

27 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=8528 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- (In reply to Quanah Gibson-Mount from comment #1) > --On Friday, November 04, 2016 12:41 AM +0000 openldap-its(a)OpenLDAP.org > wrote: > > Here's the full text, since the web form apparently ate it: > > When doing a full replace on all values for olcAccess, things work > incorrectly if the values provided are not in numeric sorted order. This > is problematic when using tools like ldapvi who do alphabetic sort. It is > trivial to reproduce the problem using the following example LDIFs: > > cat > replace_ordered.ldif <<EOF > dn: olcDatabase={1}mdb,cn=config > changetype: modify > replace: olcAccess > olcAccess: {0}to dn.exact="cn=0" by * none > olcAccess: {1}to dn.exact="cn=1" by * none > olcAccess: {2}to dn.exact="cn=2" by * none > olcAccess: {3}to dn.exact="cn=3" by * none > olcAccess: {4}to dn.exact="cn=4" by * none > olcAccess: {5}to dn.exact="cn=5" by * none > olcAccess: {6}to dn.exact="cn=6" by * none > olcAccess: {7}to dn.exact="cn=7" by * none > - > EOF > > cat > replace_ordered_mixup.ldif <<EOF > dn: olcDatabase={1}mdb,cn=config > changetype: modify > replace: olcAccess > olcAccess: {7}to dn.exact="cn=7" by * none > olcAccess: {1}to dn.exact="cn=1" by * none > olcAccess: {4}to dn.exact="cn=4" by * none > olcAccess: {3}to dn.exact="cn=3" by * none > olcAccess: {5}to dn.exact="cn=5" by * none > olcAccess: {0}to dn.exact="cn=0" by * none > olcAccess: {6}to dn.exact="cn=6" by * none > olcAccess: {2}to dn.exact="cn=2" by * none > - > EOF > > With the initial config as: > > olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * > none > olcAccess: {1}to attrs=shadowLastChange by self write by * read > olcAccess: {2}to * by * read > > When the ordered version is done, the correct result occurs: > > olcAccess: {0}to dn.exact="cn=0" by * none > olcAccess: {1}to dn.exact="cn=1" by * none > olcAccess: {2}to dn.exact="cn=2" by * none > olcAccess: {3}to dn.exact="cn=3" by * none > olcAccess: {4}to dn.exact="cn=4" by * none > olcAccess: {5}to dn.exact="cn=5" by * none > olcAccess: {6}to dn.exact="cn=6" by * none > olcAccess: {7}to dn.exact="cn=7" by * none > > However, when the unordered replaced is done, an incorrect result occurs: > > olcAccess: {0}to dn.exact="cn=0" by * none > olcAccess: {1}to dn.exact="cn=7" by * none > olcAccess: {2}to dn.exact="cn=2" by * none > olcAccess: {3}to dn.exact="cn=1" by * none > olcAccess: {4}to dn.exact="cn=4" by * none > olcAccess: {5}to dn.exact="cn=3" by * none > olcAccess: {6}to dn.exact="cn=5" by * none > olcAccess: {7}to dn.exact="cn=6" by * none > > Since we are doing a replace of all values, it should not be trying to > reweight the operation. Instead, the values should just be numeric sorted > and then written out accordingly, so one ends up with the same result as in > the ordered case. This ITS is invalid. The frontend is not trying to reweight the operation, but you're giving it invalid input. It processes each value in the order it was given. You put {7} first but at that point in time, there aren't 7 values in the attribute, so it goes "at the end". The 2nd input is {1}, which gets put into the 2nd slot, so you have {7}, {1}. The 3rd input is {4} but there are only 2 values, so it goes at the end in the 3rd slot. The 4th input is {3} so it gets inserted into the 3rd slot and pushes the previous value in the 3rd slot into the 4th slot. The 5th input is {5} so it goes at the end. The 6th input is {0} so it gets inserted into the 1st slot and pushes everything else out by 1. The 7th input is {6} so it goes at the end. The 8th input is {2} so it gets inserted in the 3rd slot and pushes everything else out by 1. Closing this ITS. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9405] New: Link to Administrator's Guide is 404
by openldap-its＠openldap.org 23 Nov '20

23 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9405 Issue ID: 9405 Summary: Link to Administrator's Guide is 404 Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: p.boven(a)xs4all.nl Target Milestone: --- On the 'software' page (https://www.openldap.org/software/), the link to the "Administrator's Guide" page currently gives a 404 error. The admin page link points to https://www.openldap.org/doc/admin/, but this should apparently be https://www.openldap.org/doc/admin24/ -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9402] New: Add support for LDAP_MATCHING_RULE_IN_CHAIN (1.2.840.113556.1.4.1941)
by openldap-its＠openldap.org 23 Nov '20

23 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9402 Issue ID: 9402 Summary: Add support for LDAP_MATCHING_RULE_IN_CHAIN (1.2.840.113556.1.4.1941) Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: vdanjean.ml(a)free.fr Target Milestone: --- Hi, The memberof overlay add support for memberOf attributes. But, when using nested groups, user group membership must be handled on each ldap client. The current implementation allows one to only retrieve direct group ownership. Nested group membership must be done by client recursive lookup. Microsoft Active Directory provides a way to do the recursive lookup at server side: https://ldapwiki.com/wiki/LDAP_MATCHING_RULE_IN_CHAIN It would be really useful if openldap (slapd) was also able to do the same. Regards, Vincent PS: I set the component to overlays in this bugs report, but I'm not sure it should be implemented into the overlays memberof itself. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9399] New: OpenLDAP build fails due to lloadd
by openldap-its＠openldap.org 20 Nov '20

20 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9399 Issue ID: 9399 Summary: OpenLDAP build fails due to lloadd Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: tero.saarni(a)est.tech Target Milestone: --- Cloning current git head and running build steps according to INSTALL fails: ./configure make depends The error is following: Entering subdirectory lloadd make[2]: Entering directory '/home/tsaarni/work/openldap/servers/lloadd' make[2]: *** No rule to make target 'depend'. Stop. make[2]: Leaving directory '/home/tsaarni/work/openldap/servers/lloadd' make[1]: *** [Makefile:333: depend-common] Error 1 make[1]: Leaving directory '/home/tsaarni/work/openldap/servers' make: *** [Makefile:354: depend-common] Error 1 The reason is that "autoreconf" results have not been committed to git. Running autoreconf && ./configure && make depend && make works. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8839] never use md5 and/or sha1, use sha-3 512 and/or blake3, file signing
by openldap-its＠openldap.org 17 Nov '20

17 Nov '20

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

1 0

[Issue 8839] never use md5 and/or sha1, use sha-3 512 and/or blake3, file signing
by openldap-its＠openldap.org 17 Nov '20

17 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=8839 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- generation of sha3-512 is now in for 2.5 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8747] LDAP load balancer daemon (lloadd)
by openldap-its＠openldap.org 17 Nov '20

17 Nov '20

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

1 0

[Issue 8747] LDAP load balancer daemon (lloadd)
by openldap-its＠openldap.org 17 Nov '20

17 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=8747 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED Keywords|OL_2_5_REQ | --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 46ddb403 by Ondřej Kuzník at 2020-11-17T17:15:40+00:00 lloadd ahoy • c596b797 by Ondřej Kuzník at 2020-11-17T17:15:40+00:00 Backend configuration • 8e0a6119 by Ondřej Kuzník at 2020-11-17T17:15:40+00:00 Startup adjustment • 1a452490 by Ondřej Kuzník at 2020-11-17T17:15:40+00:00 Update connection init • bf66b48f by Ondřej Kuzník at 2020-11-17T17:15:40+00:00 Upstream connection setup • 79f7e79f by Ondřej Kuzník at 2020-11-17T17:15:40+00:00 Set up connections in the worker threads • b49932d6 by Ondřej Kuzník at 2020-11-17T17:42:43+00:00 Connection write support • 93fe1d2b by Ondřej Kuzník at 2020-11-17T17:42:44+00:00 Operation parsing • fd5b9cdb by Ondřej Kuzník at 2020-11-17T17:42:44+00:00 This is a proxy now • 5bdb4e15 by Ondřej Kuzník at 2020-11-17T17:42:44+00:00 Update maximum number or parameters for backend • 3d1ea469 by Ondřej Kuzník at 2020-11-17T17:42:44+00:00 Authenticate the upstream connection if configured • 2fbc8ca4 by Ondřej Kuzník at 2020-11-17T17:42:44+00:00 Rename backend mutex • f37e7757 by Ondřej Kuzník at 2020-11-17T17:55:45+00:00 Response handling, exploit optional bervals • 4ad8ecd4 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Logging improvements • e5f68bcf by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Option for response handling • 639c5912 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Client authentication • 9309bc94 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Make features global • 59291ba4 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Proxyauthz support • 94ee62a4 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Switch bindkey to use Backend instead of bindconf • 798e215e by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Add connection number config • 673513a0 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Maintain the configured amount of connections per backend • dc5e2538 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Configuration part for retry timeouts • 463bcdd2 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Update backend progress tracking • 8b1703d2 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Implement backend retry timeouts • b6b3f35a by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Fix proxyauthz handling • 2e2c8666 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 There might be errors before we save the operation in c_ops • 50f5c4be by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Report initial bind errors to client • 54cd3a27 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Reject operations when binding • e5fcf175 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Save connection ids on operation for logging purposes • 8f5bae92 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Pending operation tracking and limiting • 6c8b2acc by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Do not leak addrinfos • c0d254a4 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Do not leak BerElements • fba4bed6 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 connection reference counting • cddc9632 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Do not clear c_pendingber on short write • 028f2869 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 On a failed bind, stop the callback from firing again Not a problem but causes a slew of calls to upstream_bind_cb that will all fail in the same way. • 837a6068 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Rework client_read_cb along the lines of upstream • ea7e40b8 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Shutdown handling • 9d66c26b by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Operation reference counting • 7a29fabd by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Destroy the unbind operation when acted upon • c5584fd3 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Do not leak responses to abandoned ops • 07b5744c by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Retain a reference around for handle_responses • 77f2c571 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Reset c_*ber after freeing and check c_pendingber race • 6899d012 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Do not bother to write to a dying connection • 8eb7f3fb by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Stop the read callback on a dead connection. The connection might be ready to read (close) but if we can't destroy it yet, we don't want the callback to trigger all the time or process new data. • 9ebe5acb by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Clean up events properly • 643194e7 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Revert connection/operation mutex order. There was still a race where the connection could be freed as the operation was still being used. • 58a880bc by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Convert backend and upstream management to use CIRCLEQ. This alone doesn't make the server do a round robin. • e65cd387 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Round-robin for upstream connections • 53015aa4 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Round robin for backends. Several threads calling backend_select might reset current_backend to a different place, there are two options to deal with that: - just let the last rotation win (the current approach) - detect whether first == current_backend and only replace then Not sure which one is more useful, going with the simpler. • ee288cfc by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Fix refcounting for all code paths • 37a474b5 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Fix error handling wrt. its callers • d020897f by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Initialise listeners after all workers have been • f4afc069 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Tweak connection error logging. Do not log when receiving the last bytes on a connection. Log failed writes. • cf05722b by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Lookup operations by saved connid. We reset the connection pointer on a destruction attempt, avoid the spurious asserts. • e0b8bd5f by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Free all pending operations on shutdown • 3f5dee0b by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Keep a list of active clients for shutdown purposes. Potentially for timeout detection purposes in the future. • 26f72151 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Improve logging • 1dfeca35 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Another attempt at operation/connection destroy interaction. • 10824868 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Only enable verifycredentials if libldap does • 8d85912a by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 lloadd documentation • 015f8934 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 First test for load balancer • 0a075905 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Second test • 3fa8a0cd by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Rename listener-threads to reflect the option • 495dfa69 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Split client/upstream PDU size limits • a8a0fe26 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Documentation updates • c228bd11 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Be consistent with bind responses on no upstream • 5b1ad431 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Handle upstream connection shutdown properly • 7eeb5bb8 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Forward controls correctly in the face of proxyauth • 0e7792e8 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Borrow liblber code to get abandon processing to work • 6ee21f11 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Split bind configuration from backends • 961b600a by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Rework proxyauthz handling • 9d3b998a by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Document new bind configuration • 873d6fa3 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Handle backend unsolicited response properly • 05f2ac25 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Unify logging output • af7ce80c by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Remember and clear bind status correctly • 37cff373 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Manage connection refcnt better • 88390159 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 On connection shutdown, free op from the correct side • 545198c7 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Simplify abandon processing • 0ff462b6 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Fix issues in bind response handling • 46fe0143 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Make sure operation stays alive when we process it • 887c2661 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Update tests to match latest configuration layout • baf1feab by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Handle asynchronous connect properly • 95df8a1e by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Adjust backend operation counting • 33a99355 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Unblock the client when we can't find an upstream If we can't find an upstream, we keep the client around, so it needs to be unblocked. • 1dd0e513 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Only one bind at a time • 30e538e8 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Realign logging levels. Stats now logs all operations, stats2 additionally intermediate messages (search entries). • 1740f36b by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Fix emfile handling • 65def943 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 More logging improvements • 70464443 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Do not read on the last iteration. When the pdu processing limit is hit, we still attempt to read another PDU. If we succeed, the ber_get_next call in the read callback will abort since a full PDU is already present. • 7b413f9e by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Update docs and defaults • 7b7f9724 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Avoid a deadlock with client • 16010e5e by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 More logging improvements • 622b87d5 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Make ready only when still alive • 31074213 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 TENTATIVE: communicate more for op destroy race • cda8411c by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Close up the race • 0ad91e05 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Do not back off until we get a failure • d4225924 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 CLOSING is another potential state we could be in • 6140cdf6 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Handle a client connection disconnected from op • f7cf34e6 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Reset connection state on abandon • e03c9e6f by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Stop processing if we freed the client • 532fc1bf by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Shorten time operation_mutex is locked • 362d5503 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Do not crash when closing both client and upstream • 96b7619a by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Do not unlock client unless we are destroying it • 5fcef01d by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Switch from a global mutex • cfeb4d82 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Set binding state after we have dropped all ops • 96f49393 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Add a load test • 8d93e0ba by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Unify connection locking and I/O • d22db36c by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 lload_libevent_init can fail and wants to log • 0b353106 by Ondřej Kuzník at 2020-11-17T17:55:46+00:00 Refactor operation_send_reject • c60ef739 by Ondřej Kuzník at 2020-11-17T17:58:13+00:00 Rework upstream conn setup • 7cd531c0 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Improve spec conformance, logging • 11f47438 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Exop support At the moment, no exops are processed internally, all are passed on unchanged. • b801ca17 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Rename macros and symbols to lloadd • f27517af by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Rename bind handlers • abab7e46 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Move client related functions to client.c • 5ee4b676 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Move bind handling to bind.c • ccf75c96 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Update write timeout to timeval • 063981a0 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Respond to timeout events properly • a0cd41ec by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Upstream TLS support • 1b46f866 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Client TLS support • f87127df by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Set up TLS context for backends • b4d7e8af by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 We should just be able to call backend_retry • 0cfd4fca by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Make timeouts common and redo connection read timeouts • a0ec50b3 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Upstream queues ordered by c_connid In preparation for operation timeout events. • 17900184 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Record operation activity times • 8ba44630 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Factor out abandon message preparation • aecc62c0 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Introduce operation timeout machinery • c386d527 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Protect currently impossible branch • 5cbd30de by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Log timed out connections more clearly • ea836279 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 request_abandon RFC4511 conformance • c7e3437e by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Update test suite • 8bc7650a by Nadezhda Ivanova at 2020-11-17T17:58:14+00:00 Clean ups and renames to coexist with slapd • 37cd5f21 by Nadezhda Ivanova at 2020-11-17T17:58:14+00:00 Enable compilation of the load balancer as a module To compile the balancer as a slapd module, pass --enable-balancer=mod to ./configure Use --enable-balancer(=yes) to compile as standalone server. • c91d61cf by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Do not copy files from slapd, just link them • 66f06f3f by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Initial extension to upstream selection • 1fd7249f by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 RFC4511 says Binds do not abandon, send a "reset" bind instead • ddd1acc3 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Passing the client directly will allow clearing it from op • 21a22d1b by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Refactor request parsing and sending. We have to do most of out processing before we send the request over to the upstream. If we don't, we might be too late and the response might have arrived already. • 003a35c6 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 SASL bind support Introduces pinned operations. When SASL bind finishes, we might still have to maintain a link between the client an an upstream for future bind operations if we got a SASL Bind in Progress result code. We zero out the msgids and remember a server-unique identifer on the client and the relevant operation that lets us retrieve that link again. This operation is reclaimed just like anything else when connections drop. Hopefully, this should work for LDAP TXN and VC Exop support with SASL later as well since it allows for many-to-many links to exist. • ee893ae1 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Handle EXTERNAL mechanism Will only try to extract the TLS client certificate name if used during the last handshake. • 72ca7112 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Do not compare c_auth when NULL • c52328f6 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Clear c_auth on every bind request For a new bind request, this is obvious, for SASL bind requests, we do not know the final identity until we have finished handling it, make sure it stays empty until then. • 5c1245de by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Manage c_sasl_bind_mech on upstream • 2ba83368 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Operation abandon related fixes • cbc0ec04 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Fix pinned operation forwarding • 205db0bf by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Reset pin on simple bind • c957bb91 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Add SASL documentation on SASL handling • 7a69017f by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Resolve authzid after a successful auth • 9baa56ad by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Update tests to support lloadd as a module • 2d330325 by Nadezhda Ivanova at 2020-11-17T17:58:14+00:00 Lload cn=monitor initial implementation • 77716069 by Nadezhda Ivanova at 2020-11-17T17:58:14+00:00 Use slapd's config.h • 678fa100 by Nadezhda Ivanova at 2020-11-17T17:58:14+00:00 Convert the load balancer into a backend • dab90547 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Rework monitor startup Takes care of dealing with monitor not present/not configured and fix a monitor startup issue. • 22818e85 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Module shutdown • db5966f6 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 More meaningful connection type reporting • 485a1697 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Implement pause handlers • 9bd90a74 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Fix a race on bind response processing. During response processing, an upstream connection could be marked ready after a different bind had already been allocated to it, thus allowing two binds to be in progress on the same connection. • 00116847 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Cleanup sasl_bind_mech resets • bea9bfb3 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Move op counting to operation_init • ca646cd0 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Fix operation counts Trying to abandon an operation does not automatically make it completed, it might have failed already but we're just racing to reach the client to record that. • 7f22bac4 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Introduce a new connection status - gentle shutdown • bf9f99dd by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Split backend destruction from resetting it • a7f8f58a by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 expose task functions for invalidation • cfe90658 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Introduce infra to handle config changes • edfb3d73 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Fix operation status tracking. An operation is rejected iff it has to be dropped before we can find an upstream for it (unless we handle it ourselves, that is). At that point it is failed unless completed successfully. This makes a difference for multi-stage binds which alternate between 'failed' (we are waiting on a server response) and 'completed' (server did what we asked them to, waiting on client to continue). • d954216f by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Change log level for unsolicited response • 70ae4af6 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Fix interaction of graceful connection closing and SASL bind support • bace7959 by Nadezhda Ivanova at 2020-11-17T17:58:14+00:00 Enable dynamic configuration • 3a6b3995 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Reflect backend URI change in cn=monitor • 4c355deb by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Record the backend name • 362f1647 by Ondřej Kuzník at 2020-11-17T17:58:14+00:00 Deal with no backends being configured • 05d6aae4 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Rework lloadd startup • b1c098ad by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Module shutdown support • 1ea5ee1f by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Do not unlock upstream without referencing its dying ops • 07401e58 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Implement runtime monitor (un)registration Unregistration is a hack and we shoould either make the subsystems into an entry (if monitor allows subentry generation) or implement subsystem unregistration in back-monitor. • db939eeb by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Protect operation when abandoning • 0314f95d by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Work around libevent base not waking up on shutdown • b039e7c1 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Keep a reference around for the bind task • 6b10c298 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Record pending DNS resolution to be able to cancel • db3961f4 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Record connect task to allow canceling it • 93d20459 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Make io-threads modification startup-only • 757c8bed by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Switch to ldap_parse_url_ext This simplifies port parsing in the end. Also pass the url to ldap_open_listener in anticipation of incremental listener config. • bd7a6f67 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Introduce lload_open_new_listener • f1ea9da3 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Reorganise listener support in cn=config and module startup • 513659c6 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Document config behaviour • 00806dd3 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 libevent 2.0 support • f4a2fdd4 by Nadezhda Ivanova at 2020-11-17T17:58:15+00:00 Fix a new backend not being operational if added via cn=config • 241f65b9 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Fix a race in managing b_dns_req • 2a813cb0 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Clean up backend_retry and its callers. • 638f8a2c by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Tighten checks on retry management • b4f43ed8 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Refactor backend reset Reuse the connection walking facility in timeout management. • 3bd2d748 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Reuse connection_walk for client matters • 63efcd63 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Reuse connection walking in monitor for upstreams too • ef0028e5 by Nadezhda Ivanova at 2020-11-17T17:58:15+00:00 Initial implementation of cn=config testing script • 25a4d684 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Permit lloadd to share slapd TLS context • 9444dfc9 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Simplify pause handling Gets rid of a race where unpause+pause fired in a quick succession would miss the event_base_loopbreak() call. • 05e0906f by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Fix backend starttls= setting being ignored • 50a021a3 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Do not enforce a valid ld in lutil_sasl_interact • 4b3d2114 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Introduce SASL support for upstream connections • 78f25a3c by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 A failed cn=config ADD needs to be handled • 34ddaa5f by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Tests for monitoring support • bd3da732 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Add TLS tests • c0872442 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 SASL and proxyauthz tests • 81ead4a5 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Fix races with backend_retry • aab6af1c by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Switch to LDAP_OTHER when handling a lost upstream. LDAP_UNAVAILABLE signals "the server is shutting down or a subsystem necessary to complete the operation is offline", so intelligent clients tend to infer the connection will not be usable any more, which is not the case here. • dc1961cb by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Epoch based memory reclamation Similar to the algorithm presented in https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf Not completely lock-free at the moment. Also the problems with epoch based memory reclamation are still present - a thread actively observing an epoch getting stuck will prevent LloadConnections and LloadOperations being freed, potentially running out of memory. • f832024e by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Straighten up client pending op tracking • b49f5187 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Implement client pending operation limits • b2e57148 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Shorten to one epoch per PDU A full read cycle can take a very long time if the limits are set too high. • 959ff079 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Make sure read event is not enabled while upstream_bind is scheduled • 58d66a39 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Fix race between unlinking a client and processing incoming data • 1328777a by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Fix a SASL channel-binding leak • 62a806b2 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Thread error checking • 68b163fc by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Introduce mutex checks Switched off unless thread debugging is on, but still useful for static analysis. • 1f6d8611 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Implement read throttling when writes backlog Reject operations in such a case with LDAP_BUSY. If read_event feature is on, just stop reading from the connection. However this could still result in deadlocks in reasonable situations. Need to figure out better ways to make it safe and still protect ourselves. • 41a74b46 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Introduce the notion of experimental features • 25fff30e by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Let the last thread dispose of pending references If we're idle, there might be objects pending cleanup for the last two epochs. Unless another thread comes in and checks into a new epoch or we shut down, they will linger forever. If one of the objects was a connection, it wouldn't get closed and be stuck in CLOSE_WAIT state, potentially refusing another ligitimate connection if its socket address were to match the one we're yet to close. • dfbf25d5 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Honour keepalive settings for upstreams • dfbed44b by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Do not accept requests with msgid == 0 It is used internally to identify pinned operations and should not be encountered over the wire. • 0abf3f5b by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Flush cache before calling dispose() This needs to be confirmed: Location based atomics do not imply a full fence of the same level. So to get the code in dispose() read the actual data, it seems we need to initiate a fence. • 323bb1d9 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Handle upstream rejecting a StartTLS exop • 8557cc93 by Ondřej Kuzník at 2020-11-17T17:58:15+00:00 Add lloadd into our testing regime -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9392] New: Duplicate emails and uid's allowed
by openldap-its＠openldap.org 16 Nov '20

16 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9392 Issue ID: 9392 Summary: Duplicate emails and uid's allowed Product: OpenLDAP Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: envykappa23(a)gmail.com Target Milestone: --- If i try to add a user through ldapmyadmin i will get an error that the email/uid already exist. If i use my java code , i can add users with existing emails or uid's just fine . The email and uid should both be unique as those are what most people log in in external platforms that support SSO using LDAP. Here is my code : public void addUser(String user, String email, String pass) { Attributes attributes = new BasicAttributes(); Attribute attribute = new BasicAttribute("objectClass"); attribute.add("inetOrgPerson"); attributes.put(attribute); attributes.put("mail", email); attributes.put("userPassword", pass); attributes.put("sn", "tempUsername"); attributes.put("uid",user); connection.createSubcontext("cn=user,ou=groups,dc=demo,dc=com",attributes); } -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9395] New: contrib/slapd-modules/passwd/totp missing in 2.4.56 Release
by openldap-its＠openldap.org 14 Nov '20

14 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9395 Issue ID: 9395 Summary: contrib/slapd-modules/passwd/totp missing in 2.4.56 Release Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: kaelan(a)fouwels.com Target Milestone: --- Hello, contrib/slapd-modules/passwd/totp is missing from the 2.4.56 release, despite being in master, and checked in prior to the release window. Is this intended? -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9390] New: syncrepl: Fix debug message for size limit exceeded
by openldap-its＠openldap.org 11 Nov '20

11 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9390 Issue ID: 9390 Summary: syncrepl: Fix debug message for size limit exceeded Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: fumiyas(a)osstech.co.jp Target Milestone: --- Created attachment 778 --> https://bugs.openldap.org/attachment.cgi?id=778&action=edit Proposed patch for OPENLDAP_REL_ENG_2_4 branch In server/slapd/syncrepl.c:dn_callback(): } else if ( rs->sr_type == REP_RESULT ) { if ( rs->sr_err == LDAP_SIZELIMIT_EXCEEDED ) { Debug( LDAP_DEBUG_ANY, "dn_callback : consistency error - " "entryUUID is not unique\n", 0, 0, 0 ); } } Is this wrong debug message? -- You are receiving this mail because: You are on the CC list for the issue.

1 3

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

11 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 26 Oct '20

26 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

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

22 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9375 Issue ID: 9375 Summary: Segmentation fault on ldap_search_ext_s Product: OpenLDAP Version: 2.4.44 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 in multi-threads environment. One crash call stack. #0 0x00007f08af05392b in ber_int_sb_write () from /lib64/liblber-2.4.so.2 #1 0x00007f08af04fc0b in ber_flush2 () from /lib64/liblber-2.4.so.2 #2 0x00007f08af281f71 in ldap_int_flush_request () from /lib64/libldap_r-2.4.so.2 #3 0x00007f08af282352 in ldap_send_server_request () from /lib64/libldap_r-2.4.so.2 #4 0x00007f08af2826da in ldap_send_initial_request () from /lib64/libldap_r-2.4.so.2 #5 0x00007f08af27153a in ldap_pvt_search () from /lib64/libldap_r-2.4.so.2 #6 0x00007f08af2716aa in ldap_pvt_search_s () from /lib64/libldap_r-2.4.so.2 #7 0x00007f08af271780 in ldap_search_ext_s () from /lib64/libldap_r-2.4.so.2 Another one: [0] /usr/lib64/liblber-2.4.so.2.10.7!ber_sockbuf_ctrl + 0x1ac [1] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_mark_select_clear + 0x2f [2] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_free_connection + 0x2b3 [3] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_int_bisect_insert + 0x4a5 [4] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_int_bisect_insert + 0x1bd [5] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_abandon_ext + 0x5a [6] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_abandon + 0x26 [7] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_pvt_search_s + 0xec [8] /usr/lib64/libldap_r-2.4.so.2.10.7!ldap_search_ext_s + 0x40 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

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

22 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9374 Issue ID: 9374 Summary: Segmentation fault on ldap_ld_free Product: OpenLDAP Version: 2.4.44 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 multiple threads environment. #0 0x00007f13daa9b92b in ber_int_sb_write () from /lib64/liblber-2.4.so.2 #1 0x00007f13daa97c0b in ber_flush2 () from /lib64/liblber-2.4.so.2 #2 0x00007f13dacee6c7 in ldap_send_unbind () from /usr/lib64/libldap_r-2.4.so.2 #3 0x00007f13dacf700e in ldap_free_connection () from /usr/lib64/libldap_r-2.4.so.2 #4 0x00007f13dacee1bf in ldap_ld_free () from /usr/lib64/libldap_r-2.4.so.2 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

Exhausting Locked SEM_UNDO Semaphores on MacOS
by Kris Zyp 20 Oct '20

20 Oct '20

In LMDB, if you attempt to open more than 10 transactions (on different environments) on one process on MacOS, then mdb_txn_begin will fail. This can be reproduced by opening 11 different database environments in one process, and calling mdb_txn_begin (as write transactions) on each one. The 11th one will return EINVAL. I believe this is because (on this OS, MacOS 10.13.6) the System V semaphores have a limit of 10 SEM_UNDO locked semaphores on one process. So when mdb_txn_begin attempts to open an 11th transaction, the mdb_sem_wait/semop call fails, returning EINVAL. I was testing with latest LMDB from mdb.master. Once I finally debugged this and figured out the issue, I have been able to work around it by compiling with MDB_USE_POSIX_SEM which seems to resolve the issue. But this still leaves a few questions: Is there any issue with compiling with MDB_USE_POSIX_SEM on MacOS? Would it be better if LMDB defaulted to this shared lock implementation for this OS? And/or would there be value in LMDB providing a more specific error message in this situation? The documentation doesn't indicate EINVAL as a possible return value for mdb_txn_begin, and this is a very generic error with little indication of the root problem, that was rather confusing to me, at least. Or is there an expectation that processes can only open a limited number of database environments (and have open transactions on them)? (Our server typically has about 30 environments open with about 2-16 dbs/env, with many concurrent transactions, without issue on other OSes.) I would be happy to put together a patch for this, but I am not sure of the reasons for the selection of the different shared lock implementations on different OSes. Anyway, I'd be glad to help contribute a patch if there is a specific way this should work. Thank you!

2 6

[Issue 9369] New: Logging based on severity
by openldap-its＠openldap.org 15 Oct '20

15 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9369 Issue ID: 9369 Summary: Logging based on severity Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gdb91(a)protonmail.com Target Milestone: --- Currently OpenLDAP logging can be controller per area (subsystem) for example "trace function calls" or "debug packet handling". It would be good to have logging based on severity levels such as INFO, DEBUG, ERROR, WARNING, CRITICAL, etc., something that could be set up at run time. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8820] ldap_get_attribute_ber() function needs to be documented
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

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

1 0

[Issue 8874] --with-fetch incorrectly links libcom_err
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

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

1 0

[Issue 8659] accesslog man page updates
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

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

1 0

[Issue 7129] slapo-valsort(5) missing description of LDAP_CONTROL_VALSORT
by openldap-its＠openldap.org 14 Oct '20

14 Oct '20

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs