openldap-bugs July 2024

openldap-bugs@openldap.org

1 participants
132 discussions

[Issue 9920] New: MDB_PAGE_FULL with master3 (encryption) because there is no room for the authentication data (MAC)
by openldap-its＠openldap.org 25 Oct '24

25 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9920 Issue ID: 9920 Summary: MDB_PAGE_FULL with master3 (encryption) because there is no room for the authentication data (MAC) Product: LMDB Version: unspecified Hardware: x86_64 OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: info(a)parlepeuple.fr Target Milestone: --- Created attachment 915 --> https://bugs.openldap.org/attachment.cgi?id=915&action=edit proposed patch Hello, on master3, using the encryption at rest feature, I am testing as follow: - on a new named database, i set the encryption function with mdb_env_set_encrypt(env, encfunc, &enckey, 32) - note that I chose to have a size parameter (The size of authentication data in bytes, if any. Set this to zero for unauthenticated encryption mechanisms.) of 32 bytes. - I add 2 entries on the DB, trying to saturate the first page. I chose to add a key of 33 Bytes and a value of 1977 Bytes, so the size of each node is 2010 Bytes (obviously the 2 keys are different). - This passes and the DB has just one leaf_pages, no overflow_pages, no branch_pages, an a depth of 1. - If I add one byte to the values I insert (starting again from a blank DB), then , instead of seeing 2 overflow_pages, I get an error : MDB_PAGE_FULL. - this clearly should not have happened. - Here is some tracing : add to leaf page 2 index 0, data size 48 key size 7 [74657374646200] add to leaf page 3 index 0, data size 1978 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to branch page 5 index 0, data size 0 key size 0 [null] add to branch page 5 index 1, data size 0 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to leaf page 4 index 0, data size 1978 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to leaf page 4 index 1, data size 1978 key size 33 [020202020202020202020202020202020202020202020202020202020202020202] not enough room in page 4, got 1 ptrs upper-lower = 2020 - 2 = 2016 node size = 2020 Looking at the code, I understand that there is a problem at line 9005 : } else if (node_size + data->mv_size > mc->mc_txn->mt_env->me_nodemax) { where me_nodemax is incorrect, as it is not taking into account that some bytes will be needed for the MAC authentication code, which size is in env->me_esumsize. me_nodemax is calculated at line 5349: env->me_nodemax = (((env->me_psize - PAGEHDRSZ ) / MDB_MINKEYS) & -2) - sizeof(indx_t); So I substract me_esumsize with a "- env->me_esumsize" here: env->me_nodemax = (((env->me_psize - PAGEHDRSZ - env->me_esumsize) / MDB_MINKEYS) & -2) - sizeof(indx_t); I also substract it from me_maxfree_1pg in the line above, and in pmax in line 10435. I do not know if my patch is correct, but it solves the issue. Maybe there are other places in the code where the me_esumsize should be substracted from the available size. By example, when calculating the number of overflow pages in OVPAGES, it does not take into account me_esumsize, but I think it is ok, because there is only one MAC for the entire set of OV pages, and there is room for it in the first OV page. See the attached proposed patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 40

[Issue 9982] New: Linker error when building with LDAP_CONNECTIONLESS
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9982 Issue ID: 9982 Summary: Linker error when building with LDAP_CONNECTIONLESS Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: invokesus+openldap(a)gmail.com Target Milestone: --- Created attachment 942 --> https://bugs.openldap.org/attachment.cgi?id=942&action=edit Build log I'm encountering the following linker error when building from the master branch, with LDAP_CONNECTIONLESS defined. /nix/store/jbnmj9fljgnfyc1iswnrpfhlkpnnwiii-binutils-2.39/bin/ld: ./.libs/libldap.so: undefined reference to `ber_sockbuf_io_udp' Seems to have been happening since https://git.openldap.org/openldap/openldap/-/commit/4a87d7aad200aaa91cb0cb8…. Attaching the full build log. Also, attaching in the next update, a patch to fix the error. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9356 Issue ID: 9356 Summary: Add list of peerSIDs to consumer cookie to reduce cross traffic Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If we add a list of peersids to the cookie, each consumer can tell the providers who else the consumers talk to and then the provider can omit sending updates to that consumer, originating from those peers There's some special handling needed if a connection dies If a consumer loses one of its peer connections, and after N retries is still not connected, it should send a new cookie to its remaining peers saying "here's my new peer list" with the missing one removed. Likewise, if a retry eventually connects again, it can send a new cookie again Make that peer list reset configurable in the syncrepl config stanza. This can help account for end admin knowledge that some links may be more or less stable than other ones. The idea here is that if one of your other peers can still see the missing peer, they can start routing updates to you again It should abandon all existing persist sessions and send a new sync search with the new cookie to all remaining peers For consumer side, also means adding the sid for a given provider into the syncrepl stanza to save on having to try and discover the peer sid. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Bug 9219] New: Streamline tool API for 2.5
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9219 Bug ID: 9219 Summary: Streamline tool API for 2.5 Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The current tool API is a mess and needs fixing for 2.5. This affects things like slapacl (The fix for bug#7920 was a kludge to deal with this, needs revisiting). -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Issue 10242] New: Improve syncrepl client traceability
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10242 Issue ID: 10242 Summary: Improve syncrepl client traceability Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- The o_log_prefix in do_syncrepl()'s internal operation could be tweaked to contain the rid=..., that would significantly improve syncrepl traceability in the server logs and gdb. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9813] New: Incompatibility between remoteauth and ppolicy overlays
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9813 Issue ID: 9813 Summary: Incompatibility between remoteauth and ppolicy overlays Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: thierry.pubellier(a)paris.fr Target Milestone: --- Hi, We are planning to use OpenLDAP as a proxy for some users in our Active Directory servers, using remoteauth overlay. We want this OpenLDAP instance to also implement an account lockout policy, preventing the lockout on our internal Active Directory servers. But there seems to be an incompatibility between remoteauth and ppolicy overlays : remoteauth won't remote authenticate a user if local userPassword attribute exists, while ppolicy overlay needs this attribute. Could there be a configuration parameter in ppolicy to allow lockout checks/modifications (which seemed to be the default behavior of OpenLDAP before ITS#7089) ? I can provide a patch if allowed. Thanks by advance, Best regards, Thierry -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10243] New: Looking to get account on OpenLDAP Gitlab
by openldap-its＠openldap.org 06 Aug '24

06 Aug '24

https://bugs.openldap.org/show_bug.cgi?id=10243 Issue ID: 10243 Summary: Looking to get account on OpenLDAP Gitlab Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ak.openldap(a)anroet.com Target Milestone: --- I'm trying to open an account on Gitlab. The purpose for having an account on gitlab is so that I can start the process of building a docker image for use in our Production K8s environment. Currently, I can only find docker images for version 2.4 and the admission controllers in out production k8s clusters isn't having none of that. I'm attempting to create an account using the following email address: ak.openldap(a)anroet.com -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10245] New: mdb_env_set_maxdbs signature appears incorrect
by openldap-its＠openldap.org 30 Jul '24

30 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10245 Issue ID: 10245 Summary: mdb_env_set_maxdbs signature appears incorrect Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: bchik(a)meta.com Target Milestone: --- The current signature for mdb_env_set_maxdbs: int mdb_env_set_maxdbs(MDB_env *env, MDB_dbi dbs); The documentation says the second parameter is intended to be the maximum number of databases, however, the parameter is typed as a DB handle. This appears to work because MDB_dbi is typedef'd to an unsigned int. I believe the intended signature would be: int mdb_env_set_maxdbs(MDB_env *env, unsigned int dbs); -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10241] New: Crash in mdb_page_search_root()
by openldap-its＠openldap.org 22 Jul '24

22 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10241 Issue ID: 10241 Summary: Crash in mdb_page_search_root() Product: LMDB Version: 0.9.24 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: david.komarek(a)whalebone.io Target Milestone: --- Hello, The LMDB is crashing in mdb_page_search_root() on following instruction `0x7f85221479d2 movzwl 0xa(%rdx),%eax`. This instruction corresponds to following line in source code - https://github.com/LMDB/lmdb/blob/LMDB_0.9.24/libraries/liblmdb/mdb.c#L5485 (while access mp_flags in MDB_page structure) Here is callstack as generated by core dump (without symbols as we're using package from Ubuntu repositories) ``` Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f85221479d2 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 No symbol table info available. #1 0x00007f8522147d15 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 No symbol table info available. #2 0x00007f8522148432 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 No symbol table info available. #3 0x00007f8522148a70 in mdb_get () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 No symbol table info available. ``` Translation ``` #0 mdb_page_search_root() #1 mdb_page_search() #2 mdb_cursor_set() #3 mdb_get() ``` Registers in time of crash: ``` rax 0x2 2 rbx 0x7ffcd8d2a100 140723946168576 rcx 0x3 3 rdx 0x7f825baf7000 140197860700160 rsi 0x1000 4096 rdi 0x7f851c00f4d0 140209677202640 rbp 0x0 0x0 rsp 0x7ffcd8d29e40 0x7ffcd8d29e40 r8 0x7ffcd8d29e50 140723946167888 r9 0x7f851c00f5b8 140209677202872 r10 0x7f851c003090 140209677152400 r11 0x2ce33e6c02ce33e7 3234497591006606311 r12 0x0 0 r13 0x7ffcd8d2a510 140723946169616 r14 0x79 121 r15 0x7f851c003098 140209677152408 rip 0x7f85221479d2 0x7f85221479d2 eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 k0 0x40 64 k1 0xfffff0f0 4294963440 k2 0xff01 65281 k3 0xffffffff 4294967295 k4 0xffffffff 4294967295 k5 0xffffffff 4294967295 k6 0xffffffff 4294967295 k7 0x0 0 ``` Our setup is following: We have single process (running in separate container) which reads and writes to LMDB. It opens environment with following flags MDB_NORDAHEAD|MDB_WRITEMAP|MDB_NOTLS|MDB_NOSYNC. The environment contain several DBs. All DBIs are open with MDB_CREATE flag. Transactions are open without flags. On the other hand we have several processes running in the single container, which are only allowed read (these processes crash). The environment is open with following flags MDB_NORDAHEAD|MDB_WRITEMAP|MDB_NOTLS|MDB_RDONLY. All DBIs are open without flags. Transactions are open with MDB_RDONLY flag. Could you please investigate it? If you will need some other artifacts or comments, please let me know. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10240] New: Information required about the end of support date for OpenLDAP ver 2.6.3
by openldap-its＠openldap.org 17 Jul '24

17 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10240 Issue ID: 10240 Summary: Information required about the end of support date for OpenLDAP ver 2.6.3 Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: bluesoulprince(a)gmail.com Target Milestone: --- Hi Team, As we have integrated OpenLDAP 2.6.3 version in our application, we would like to know the community support availability end of date for this version, to plan our application maintenance accordingly. Could you please help us with this information. Thanks, Vivek S -- You are receiving this mail because: You are on the CC list for the issue.

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2024