openldap-bugs June 2023

openldap-bugs@openldap.org

2 participants
114 discussions

[Bug 9218] New: Revist entry_release handling in slapo-pache, slapo-translucent
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9218 Bug ID: 9218 Summary: Revist entry_release handling in slapo-pache, slapo-translucent Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From a past discussion with hyc on 2.5 items: [13:57] <hyc> there's a nagging problem though, pcache's entry_release function needs to distinguish between its backend actually freeing the entry, or being a no-op [13:57] <hyc> so it can decide whether to return success or continue [13:58] <hyc> the patch to translucent sidesteps the question, by avoiding other overlays [13:58] <hyc> but we need to revisit this in 2.5 -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 9217] New: Audit all schema definitions to have official non-experimental OIDs where possible
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9217 Bug ID: 9217 Summary: Audit all schema definitions to have official non-experimental OIDs where possible 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: --- From a past discussion with hyc on 2.5 requirements: [09:27] <hyc> we also need to audit all of these schema defs [09:27] <hyc> we're supposed to have official, non-experimental OIDs for released schema [09:28] <hyc> accesslog is still using 666, experimental arc [09:29] <hyc> I think this means we should polish up the logschema draft, Informational status, and publish it again as final -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 9216] New: Port autoca to gnutls
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9216 Bug ID: 9216 Summary: Port autoca to gnutls Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- For 2.5, support building and running the autoca overlay with GnuTLS. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 9204] New: slapo-constraint allows anyone to apply Relax control
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9204 Bug ID: 9204 Summary: slapo-constraint allows anyone to apply Relax control Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- slapo-constraint doesn't limit who can use the Relax control, beyond the global limits applied by slapd. In practice, for many modifications this means any configured constraints are advisory only. In my opinion this should be considered a bug, in design if not implementation. I expect many admins would not read the man page closely enough to realize the behaviour does technically adhere to the letter of what's written there. Either slapd should require manage privileges for the Relax control globally, or slapo-constraint should perform a check for manage privilege itself, like slapo-unique does. Quoting ando in https://bugs.openldap.org/show_bug.cgi?id=5705#c4: > Well, a user with "manage" privileges on related data could bypass > constraints enforced by slapo-constraint(5) by using the "relax" > control. The rationale is that a user with manage privileges could be > able to repair an entry that needs to violate a constraint for good > reasons. Note that the user: > > - must have enough privileges to do it (manage) > > - must inform the DSA that intends to violate the constraint (by using > the control) but such privileges are currently not being required. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Issue 10072] New: Querying for transaction memory use
by openldap-its＠openldap.org 28 Oct '23

28 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10072 Issue ID: 10072 Summary: Querying for transaction memory use Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: tagwerk19.openldap(a)innerjoin.org Target Milestone: --- It would be useful to have a way to ask liblmdb how much "dirty memory" a transaction is using, up to that point. The goal is to be able to bundle writes into fewer transactions, making best use of available memory and reducing total disc writes. It is possible for an application to count the number of writes but this has only a loose relation to the *actual* number of dirty pages flagged. The target would be to write data up until the dirty memory gets to a threshold and then commit. I see that there's a: txn->mt_dirty_room and wonder if MDB_IDL_UM_MAX - txn->mt_dirty_room would give a count of that an "aware" application could make use of (an exact count? or maybe a usable and sufficient indication?) The need for this has been sharpened with the use of systemd service files that cap the memory allowed for a process, for example: MemoryHigh=512M If the process reaches this limit and continues to write data, the system uses swap. See: https://invent.kde.org/frameworks/baloo/-/merge_requests/148 Thank you for providing and supporting LMDB -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9959] New: Expose the lloadd connection endpoints in cn=monitor for identification
by openldap-its＠openldap.org 25 Oct '23

25 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9959 Issue ID: 9959 Summary: Expose the lloadd connection endpoints in cn=monitor for identification Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- ITS#9600 introduces a way to operate on lloadd connections, however it is impossible to identify which socket this actually corresponds to. While we're at it, might also expose the current bound identity there. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10045] New: back-config operations abandoned while waiting in slap_pause_server() aren't committed to ldif
by openldap-its＠openldap.org 24 Oct '23

24 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10045 Issue ID: 10045 Summary: back-config operations abandoned while waiting in slap_pause_server() aren't committed to ldif 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: --- slap_pause_server() can take an unbounded time to process and it is possible the operation is abandoned in the meantime (e.g. the connection is lost and the loss is still noticed at this point). However the processing still goes ahead and passed onto back-ldif - where it is discarded as abandoned already so we can end up with an inconsistent view of our persistent configuration. Checking op->o_abandon again after slap_pause_server() finishes might be enough. -- You are receiving this mail because: You are on the CC list for the issue.

2 13

[Issue 9278] New: liblmdb: robust mutexes should not be unmapped
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9278 Issue ID: 9278 Summary: liblmdb: robust mutexes should not be unmapped Product: LMDB Version: unspecified Hardware: All OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: delphij(a)freebsd.org Target Milestone: --- Created attachment 736 --> https://bugs.openldap.org/attachment.cgi?id=736&action=edit A possible workaround We recently noticed that lmdb would have the memory region containing the robust mutex unmapped on mdb_env_close0(): munmap((void *)env->me_txns, (env->me_maxreaders-1)*sizeof(MDB_reader)+sizeof(MDB_txninfo)); Note that if this is the last unmap for a robust mutex, the FreeBSD implementation would garbage-collect the mutex, making it no longer visible to other processes. As the result, a second instance of the attached test.c (from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244493 with minor changes) would trigger the assertion at mdb_txn_begin() because the acquisition of the mutex would return 22 (EINVAL), because the mutex appeared to be a robust mutex, but was invalid. The attached lmdb.diff is a possible workaround for this (it would skip unmapping when setting up the robust mutex for the first time). -- You are receiving this mail because: You are on the CC list for the issue.

1 20

[Issue 10077] New: Integer overflow in util-int.c
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10077 Issue ID: 10077 Summary: Integer overflow in util-int.c Product: OpenLDAP Version: 2.6.3 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michal.pura(a)gmail.com Target Milestone: --- Created attachment 971 --> https://bugs.openldap.org/attachment.cgi?id=971&action=edit the fix proposal for ldap_pvt_gettimensec() function Hello, I found the issue with contextCNS generating process which cause that its format is invalid (minus sign in nanoseconds filed). Example: "generated new csn=20230630080704.-489933Z#000000#000#000000" The bug can introduce the minus sign in the contextCSN what could have an impact in replication process, backup restoring etc. Everywhere when the format of contextCSN is checked before processing it. According to the source code and reference documents the contextCSN nanoseconds filed should have the value from range: 000000-999999. https://www.openldap.org/faq/data/cache/1145.html The problem is in the function ldap_pvt_gettimensec() in util-int.c file. For example in line: count.QuadPart += (10 * BILLION); The value of (10 * BILLION) will be treated as 32-bit value by compilator and will cause the integer overflow. Then the random value is added to count.QuadPart what in some specific cases can produce the negative value which is returned from the function. At the end the value is passed to the function ldap_pvt_csnstr() so the contextCSN is wrongly generated (with minus sign). There is missing 'LL' qualifier, code should looks like this: count.QuadPart += (10LL * BILLION); I also suggest to change the type of _ldap_pvt_gt_offset variable from int to long long. In attachment you will find fix proposal as there are more places in the function where changes are required. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9714] New: Use xorshift in libldap/dnssrv.c
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9714 Issue ID: 9714 Summary: Use xorshift in libldap/dnssrv.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- As discussed in https://git.openldap.org/openldap/openldap/-/merge_requests/417 we may want to shift to using xorshift in libldap/dnssrv.c in a future release. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

← Newer
1
2
3
4
5
6
7
8
9
...
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2023