openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

[Issue 9042] loglevel setting that allows seeing attribute values for MOD operations
by openldap-its＠openldap.org 12 Nov '24

12 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=9042 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 4b8e60f8 by Ondřej Kuzník at 2024-10-25T20:02:19+00:00 ITS#9042 Log modify values under STATS2 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9914] New: Add OS pagesize to the back-mdb monitor information
by openldap-its＠openldap.org 12 Nov '24

12 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=9914 Issue ID: 9914 Summary: Add OS pagesize to the back-mdb monitor information Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The pagesize that back-mdb is using for pages should be exposed via the cn=monitor backend, as a remote client doing a query will not have that information available to it. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10283] New: Search result internal error: mdb_opinfo_get: thread_pool_setkey failed err
by openldap-its＠openldap.org 12 Nov '24

12 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10283 Issue ID: 10283 Summary: Search result internal error: mdb_opinfo_get: thread_pool_setkey failed err Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: asilva(a)wirelessmundi.com Target Milestone: --- Hi, From time to time i got errors when perform searches and i need to restart the server to establish the service. This is the event log when it happens: Nov 08 10:07:39 main slapd[3946463]: conn=1780 fd=182 ACCEPT from IP=113.53.215.185:41404 (IP=0.0.0.0:389) Nov 08 10:07:39 main slapd[3946463]: conn=1780 op=0 BIND dn="cn=admin,ou=users,o=cptrabajosocial.local.com" method=128 Nov 08 10:07:39 main slapd[3946463]: mdb_opinfo_get: thread_pool_setkey failed err (12) Nov 08 10:07:39 main slapd[3946463]: conn=1780 op=0 RESULT tag=97 err=12 qtime=0.000027 etime=0.000159 text=internal error Nov 08 10:07:39 main slapd[3946463]: conn=1780 op=1 UNBIND Nov 08 10:07:39 main slapd[3946463]: conn=1780 fd=182 closed In the code i found: if ( ( rc = ldap_pvt_thread_pool_setkey( ctx, mdb->mi_dbenv, data, mdb_reader_free, NULL, NULL ) ) ) { mdb_txn_abort( moi->moi_txn ); moi->moi_txn = NULL; Debug( LDAP_DEBUG_ANY, "mdb_opinfo_get: thread_pool_setkey failed err (%d)\n", rc ); return rc; } and libraries/libldap/tpool.c i see that the error 12 (ENOMEM) is returned when MAXKEYS is reached: if ( data || kfree ) { if ( i>=MAXKEYS ) return ENOMEM; ctx->ltu_key[i].ltk_key = key; ctx->ltu_key[i].ltk_data = data; ctx->ltu_key[i].ltk_free = kfree; } else if ( found ) { clear_key_idx( ctx, i ); } Found an old mail about this issue: https://openldap-technical.openldap.narkive.com/Th0WLQYh/max-numbers-of-sub… In my setup I've configured 47 MBs databases, for contacts only, one for each company in the server, so they cannot see each others data. I can't understand how it happens and how to prevent it, is there any configuration i can set to avoid reach the MAXKEYS? Thanks, -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10257] New: Documentation assessment
by openldap-its＠openldap.org 12 Nov '24

12 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10257 Issue ID: 10257 Summary: Documentation assessment Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Created attachment 1031 --> https://bugs.openldap.org/attachment.cgi?id=1031&action=edit Admin guide assessment Last month I commissioned a tech writer to review the current 2.6 Admin Guide to see what needs to be worked on before the 2.7 release. I'm attaching the report here so we can reference it. Should have distributed it sooner but Life got in the way. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10278] New: Move away from python-ldap0 in the test suite
by openldap-its＠openldap.org 29 Oct '24

29 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10278 Issue ID: 10278 Summary: Move away from python-ldap0 in the test suite Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- While python-ldap0 has a superior API, it seems the module is no longer receiving any development. We should move our python test suite over to another module that can be supported long-term. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10277] New: How to deal with desync between cn=config and back-ldif DNs
by openldap-its＠openldap.org 29 Oct '24

29 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10277 Issue ID: 10277 Summary: How to deal with desync between cn=config and back-ldif DNs Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If someone deletes a cn=config entry offline (or through bugs in cn=config, they exist, will file as I isolate), the X-ORDERED RDNs will not be contiguous. cn=config papers over this internally at a cost of never being able to modify the entries affected. Right now the only remedy is slapcat+slapadd of the whole config DB, is that the best we can do? When we detect this (doesn't always happen), should we fix the on-disk copy on startup? -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10276] New: crash using pcache overlay on mdb backend
by openldap-its＠openldap.org 29 Oct '24

29 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10276 Issue ID: 10276 Summary: crash using pcache overlay on mdb backend Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: chris.paul(a)rexconsulting.net Target Milestone: --- Created attachment 1038 --> https://bugs.openldap.org/attachment.cgi?id=1038&action=edit backtrace When using the pcache overlay with a local mdb backend, slapd crashes. The intention is to use pcache to reduce lookup times for dynamic (dynlist) groups and memberOf values. GDB backtrace attached. Config available upon request. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10268] New: Operation rate limiting
by openldap-its＠openldap.org 29 Oct '24

29 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10268 Issue ID: 10268 Summary: Operation rate limiting Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: chris.paul(a)rexconsulting.net Target Milestone: --- Please consider this request for enhancement. It would be very useful for slapd to have some basic rate limiting per connection or per IP. The monitorConnectionsOpsCompleted counts are available in cn=monitor. A dependency of cn=monitor seems reasonable. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Bug 9211] New: Relax control is not consistently access-restricted
by openldap-its＠openldap.org 25 Oct '24

25 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9211 Bug ID: 9211 Summary: Relax control is not consistently access-restricted Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- The following operations can be performed by anyone having 'write' access (not even 'manage') using the Relax control: - modifying/replacing structural objectClass - adding/modifying OBSOLETE attributes Some operations are correctly restricted: - adding/modifying NO-USER-MODIFICATION attributes marked as manageable (Modification of non-conformant objects doesn't appear to be implemented at all.) In the absence of ACLs for controls, I'm of the opinion that all use of the Relax control should require manage access. The Relax draft clearly and repeatedly discusses its use cases in terms of directory _administrators_ temporarily relaxing constraints in order to accomplish a specific task. -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs