https://bugs.openldap.org/show_bug.cgi?id=5840
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #12 from Howard Chu <hyc(a)openldap.org> ---
(In reply to Ondřej Kuzník from comment #11)
> Is this resolved with ITS#8958?
Yes
*** This issue has been marked as a duplicate of issue 8958 ***
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8958
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ralf(a)openldap.org
--- Comment #42 from Howard Chu <hyc(a)openldap.org> ---
*** Issue 5840 has been marked as a duplicate of this issue. ***
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5840
--- Comment #11 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
Is this resolved with ITS#8958?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9798
Issue ID: 9798
Summary: Clearing pending ops on Bind
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: ---
Some context first.
The only universal way of reset an arbitrary (SASL) bind in progress, at least
in my reading of RFC4511 is to send an anonymous bind op, so that's what the
load balancer does when needed (the client goes away, etc.).
Incidentally, this is also what the balancer chooses to do when the pending
bind needs to be "abandoned" when the backend doesn't respond within a
configured timeout. That's skating the edge of what RFC4511 allows, probably
just past it.
The issue:
When slapd receives a bind and another operation X (lloadd sends the above
mentioned "reset" bind) before that first bind starts processing, X gets added
into conn->c_ops_pending and does c_n_pending_ops++. Bind then eventually
invokes connection_abandon which forgets to zero out c_n_pending_ops and the
connection remains unusable forever. On the surface that's trivial to fix and a
fix is coming.
On the other hand, operation X in the pending list is actually discarded too,
so that kind of defeats the idea of trying to "abandon" the original bind and
completely reset the connection state. Question is, do we want to retain the
last bind in the pending list or does the balancer have to destroy the
connection unconditionally when a bind times out?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8524
--- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
Just like with attribute and objectclass definitions, these are stored under
cn=schema,cn=config as the file that defined them or directly in cn=config if
defined in slapd.conf directly (as you're doing here). Maybe keep them in a
file that you also include.
Don't know if we should document this behaviour or change it in some way.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7441
--- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
The inconsistency part comes from bconfig not implementing be_compare. Instead,
it relies on the frontend implementation, so while search goes through
test_filter->...->ordered_value_match and other backends use slap_compare_entry
which triggers the same, frontend's compare gets the actual values through
backend_attribute and then calls value_find_ex, which doesn't care about
SLAP_AT_ORDERED.
Afterwards, allowing attr={index} assertions to match attr={index}value and
attr={index}value to match itself only should be possible by adapting
ordered_value_match (and value_find_ex or whatever we end up calling from the
frontend).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9748
Issue ID: 9748
Summary: Deleted values of pwdFailureTime seem to reappear
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: ---
Created attachment 854
--> https://bugs.openldap.org/attachment.cgi?id=854&action=edit
accesslog for uid=dm01-R2H2-956,ou=People,dc=example,dc=com
Somehow, ppolicy seems to be able to reference values of pwdFailureTime that
had been deleted before the actual bind even started. In the attached
accesslog, trace, deletion of everything (including "20211115154510.478330Z")
is recorded from reqSession: 3, then a bind comes in and the same value is
explicitly removed again.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9800
Issue ID: 9800
Summary: ACL with set.expand in <who> clause does not work with
deref control
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
This ACL returns correct values with a normal search requesting the attribute
sudoUser:
access to
dn.subtree="ou=ae-dir"
attrs=sudoUser
val.regex="^%(.+)$"
by set.expand="(user/-1 | user/aeSrvGroup)/aeLoginGroups &
[ldap:///ou=ae-dir?entryDN?sub?(&(objectClass=aeGroup)(aeStatus=0)(cn=${v1}))]/entryDN"
read
by * none
But it does not work with a search like this using deref control:
ldapsearch -Q -E deref=aeVisibleSudoers:cn,sudoUser '(objectClass=aeSrvGroup)'
For completeness see docs and schema for aeSrvGroup:
https://www.ae-dir.com/docs.html#schema-oc-aeSrvGrouphttps://code.stroeder.com/AE-DIR/ansible-ae-dir-server/src/branch/master/fi…
--
You are receiving this mail because:
You are on the CC list for the issue.