https://bugs.openldap.org/show_bug.cgi?id=9497
Issue ID: 9497
Summary: back-ldif: test022-ppolicy failure
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
The test022-ppolicy with back-ldif fail for two issue.
1. too short pwdMaxAge
~~~
$ ./run -b ldif test022-ppolicy
(snip)
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
Password expiration test failed
~~~
The script tries test for lockout and then a test for password expiration.
It will fail if the password has expired(pwdMaxAge: 30) by the time it starts
the password expiration test.
This is a timing issue and not directly caused by back-ldif.
However, the issue is reproduced only with back-ldif in my environment.
This test passed in my environment by extending pwdMaxAge by 5 seconds, but
there may be a better way.
2. duplicate ldap control response
~~~
Reconfiguring policy to remove grace logins...
Clearing forced reset...
expr: syntax error: unexpected argument '15'
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
~~~
This is back-ldif issue.
back-ldif responds duplicate ldap control response.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5840
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
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.