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.
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.
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.
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.
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.
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.
https://bugs.openldap.org/show_bug.cgi?id=10085
Issue ID: 10085
Summary: test029 can't pass with SLAPD_USE_SASL is set
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: ---
Running make test with SLAPD_USE_SASL set will fail test029. There is even a
comment there that we can't support that functionality as-is when SASL binds
are configured. We should probably remove that part of the test or skip it
unconditionally for now.
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
https://bugs.openldap.org/show_bug.cgi?id=10095
Issue ID: 10095
Summary: Race condition causing corruption of mutexes when
closing the database
Product: LMDB
Version: 0.9.30
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: peter(a)peterzhu.ca
Target Milestone: ---
We're running into a race condition across multiple processes causing the
corruption of mutexes when a process closes the database caused by the fix for
https://bugs.openldap.org/show_bug.cgi?id=9278 (commit
https://git.openldap.org/openldap/openldap/-/commit/f683ffdc81d0edb20437cb7…).
Here's the interleaving of two processes (p0 and p1) that can cause this
situation.
p0: Opens connection to database using mdb_env_create and mdb_env_open.
...some things happen in between...
p0: Begins closing the database using mdb_env_close:
p0: Calls mdb_env_close0:
p0: Acquires write lock on the file lock using mdb_env_excl_lock.
p0: Calls pthread_mutex_destroy on the mutexes.
SWITCH TO p1
p1: Begins opening the database using mdb_env_create. Then calls mdb_env_open,
in mdb_env_open:
p1: Calls mdb_env_setup_locks:
p1: Calls mdb_env_excl_lock, but it's unable to acquire a write file lock
due to p0 holding the write file lock. It waits on acquiring a read file lock.
SWITCH TO p0
p0: Calls close on the file descriptor which releases the write lock.
SWITCH TO p1
p1: Acquires the read file lock.
p1: Does NOT call pthread_mutex_init since it did not acquire a write file
lock.
...some things happen in between...
p1: Try to lock the mutex using pthread_mutex_lock. This call fails with a
EINVAL due to locking a destroyed mutex.
I'm not sure how to actually solve this problem. We're currently mitigating
this problem by reverting the commit linked above (so no mutexes get
destroyed).
--
You are receiving this mail because:
You are on the CC list for the issue.
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.