https://bugs.openldap.org/show_bug.cgi?id=6198
--- Comment #6 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
A few open questions I can't resolve yet:
- Do we rely on OID macros from schema or let slap_control/load_extop2 register
it? The suggestions above tend to prefer OID macros but they have to be defined
in the schema (there's only one) and they're currently case-sensitive
For controls:
- Do we want to be able to use ACLs to turn non-critical controls to ignored?
- Do we want to be able to use ACLs to refuse control combinations?
- Apart from the 'to' clause, do we want it allowed in the 'by' clause as well
(when would it be useful? There's control combinations, anything else?)
I'll start with "no" to all 3 of the above for now.
As for combination with other specifiers (especially for exops), ACL checks are
issued with the operation and an entry right now, they do make sense in that
scope so password modify/DDS refresh should be in the clear. Other extops are
more of a problem:
- whoami: technically there is a DN but it doesn't have to correspond to an
entry
- verify credentials: tricky, since it's processed as a bind
- cancel: abandon can't be restricted, so probably the same
- turn: no idea
- ChainedRequest: even less of one
Probably happy for those to be impossible to restrict in this way, at least 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=8905
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |gnoe(a)symas.com
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7982
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9398
Issue ID: 9398
Summary: Stale accesslog cookie due to unclean shutdown
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db.
Depending on the syncprov overlay checkpoint settings (usually no checkpointing
is enabled on the accesslog db) this can cause the system to refuse engage in
replication at startup.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9225
Bug ID: 9225
Summary: back-mdb: Add support for PREPARE/2-phase commit
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Add support for PREPARE/2-phase commit in back-mdb
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9186
Bug ID: 9186
Summary: RFE: More metrics in cn=monitor
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Currently I'm grepping metrics from syslog with mtail:
https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/mta…
With a new binary logging this is not possible anymore.
Thus it would be nice if cn=monitor provides more metrics.
1. Overall connection count per listener starting at 0 when started. This would
be a simple counter added to:
entries cn=Listener 0,cn=Listeners,cn=Monitor
2. Counter for the various "deferring" messages separated by the reason for
deferring.
3. Counters for all possible result codes. In my mtail program I also label it
with the result type.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8943
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |SUSPENDED
--- Comment #6 from Howard Chu <hyc(a)openldap.org> ---
One major problem here is that overlays assume they all execute in the same
thread for the duration of an operation. Putting the response in the worker
thread would break overlay response callbacks.
It would be quite a lot of refactoring to make overlays thread-independent, and
that's not going to happen soon.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10255
Issue ID: 10255
Summary: OpenLDAP should leak the SSL ctx and not try to free
it in an atexit() handler
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
As mentioned in the subject, OpenLDAP incorrectly handles OpenSSL in its
destructor.
Сomprehensive information can be found here (along with a possible solution):
https://github.com/openssl/openssl/issues/25294
--
You are receiving this mail because:
You are on the CC list for the issue.