https://bugs.openldap.org/show_bug.cgi?id=9295
Issue ID: 9295 Summary: ppolicy and replication: pwdLockedTime replication fails to replicate Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: quanah@openldap.org Target Milestone: ---
If you have the following setup, a replica will hit an error during replication.
a) ppolicy is configured on provider(s) and replicas. Replica has schemachecking=on in its syncrepl configuration b) account gets locked on the replica, so pwdAccountLockedTime is set on the replica but not on the provider(s) c) admin does a MOD/ADD op against a provider for the user entry to add a value to pwdAccountLockedTime
dn: ... changetype: modify add: pwdAccountLockedTime pwdAccountLockedTime: ...
d) provider accepts this modification. e) replica rejects this modification because the resulting change means that there would be two pwdAccountLockedTime values on the account in question
Generally I believe that in this scenario, the MOD/ADD on the provider should be treated as a replace OP instead of an ADD op
https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #1 from Quanah Gibson-Mount quanah@openldap.org --- Note: only way to recover from this scenario is to completely reload the replica's db.
https://bugs.openldap.org/show_bug.cgi?id=9295
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.4.51
https://bugs.openldap.org/show_bug.cgi?id=9295
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- head:
Commits: • 4cf90e84 by Howard Chu at 2020-07-29T16:15:42+01:00 ITS#9295 use replace on single-valued attrs
RE24:
Commits: • a95890e9 by Howard Chu at 2020-07-29T22:39:32+00:00 ITS#9295 use replace on single-valued attrs
https://bugs.openldap.org/show_bug.cgi?id=9295
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #3 from Quanah Gibson-Mount quanah@openldap.org --- trunk:
Commits: • efc23cdd by Ondřej Kuzník at 2020-09-30T18:55:34+00:00 ITS#9295 Do not replace 'op'
https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #4 from Quanah Gibson-Mount quanah@openldap.org --- re24:
• 8ff00e1d by Ondřej Kuzník at 2020-09-30T21:55:05+00:00 ITS#9295 Do not replace 'op'
https://bugs.openldap.org/show_bug.cgi?id=9295
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.4.51 |2.4.54
https://bugs.openldap.org/show_bug.cgi?id=9295
Ondřej Kuzník ondra@mistotebe.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Ever confirmed|0 |1 Status|VERIFIED |CONFIRMED
--- Comment #5 from Ondřej Kuzník ondra@mistotebe.net --- The way we munge the inbound op can backfire on operations like this:
``` add: singlevalued singlevalued: new - delete: singlevalued singlevalued: old ```
Arguably, applications that do this are strange, but the protocol allows this and it's accepted on the provider.
Seems that for single-valued ops, we probably need to merge and transform retrospectively as we go and relevant changes for syncrepl_message_to_op need to be made.
https://bugs.openldap.org/show_bug.cgi?id=9295
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.4.54 |2.4.59
https://bugs.openldap.org/show_bug.cgi?id=9295
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@openldap.org |ondra@mistotebe.net
https://bugs.openldap.org/show_bug.cgi?id=9295
Ondřej Kuzník ondra@mistotebe.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS
--- Comment #6 from Ondřej Kuzník ondra@mistotebe.net --- Tracked in MR!307 https://git.openldap.org/openldap/openldap/-/merge_requests/307
https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #7 from Quanah Gibson-Mount quanah@openldap.org --- head:
Commits: • afa19de2 by Ondřej Kuzník at 2021-04-12T15:15:02+00:00 ITS#9295 Handle add+delete on a single-value attr
https://bugs.openldap.org/show_bug.cgi?id=9295
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST
--- Comment #8 from Quanah Gibson-Mount quanah@openldap.org --- RE24:
commit 95fb5f0e4d453b201c0b27955ef7f8c37b959c6c Author: Ondřej Kuzník ondra@mistotebe.net Date: Thu Apr 1 15:17:14 2021 +0100
ITS#9295 Handle add+delete on a single-value attr
https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #9 from Michael Ströder michael@stroeder.com --- (In reply to Ondřej Kuzník from comment #5)
The way we munge the inbound op can backfire on operations like this:
add: singlevalued singlevalued: new - delete: singlevalued singlevalued: oldArguably, applications that do this are strange, but the protocol allows this and it's accepted on the provider.
Note that it's not strange at all: This is the recommended client behaviour when using an ID pool entry for unique ID assignment.
I'm glad this will be fixed in 2.4.59.
https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #10 from Ondřej Kuzník ondra@mistotebe.net --- On Fri, May 28, 2021 at 10:20:59PM +0000, openldap-its@openldap.org wrote:
The way we munge the inbound op can backfire on operations like this:
add: singlevalued singlevalued: new - delete: singlevalued singlevalued: oldArguably, applications that do this are strange, but the protocol allows this and it's accepted on the provider.
Note that it's not strange at all: This is the recommended client behaviour when using an ID pool entry for unique ID assignment.
I'm not sure what the difference is to just sending a delete, then add from application's point of view? I know it shouldn't matter as the entry only needs to be consistent/valid when the operation is finished, but you're saying there are reasons to do just this...
https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #11 from Michael Ströder michael@stroeder.com --- On 5/29/21 11:46 AM, openldap-its@openldap.org wrote:
https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #10 from Ondřej Kuzník ondra@mistotebe.net --- On Fri, May 28, 2021 at 10:20:59PM +0000, openldap-its@openldap.org wrote:
The way we munge the inbound op can backfire on operations like this:
add: singlevalued singlevalued: new - delete: singlevalued singlevalued: oldArguably, applications that do this are strange, but the protocol allows this and it's accepted on the provider.
Note that it's not strange at all: This is the recommended client behaviour when using an ID pool entry for unique ID assignment.
I'm not sure what the difference is to just sending a delete, then add from application's point of view? I know it shouldn't matter as the entry only needs to be consistent/valid when the operation is finished, but you're saying there are reasons to do just this...
Deleting certain attribute values makes sure that the entry you're modifying still has its former state. So this uses the ACID properties of a single modify operation as a test-and-set operation.
Most common example is ID assignment with an ID pool entry. You want to make sure that no other LDAP client consumed the next ID in between your last read and current ID update attempt.
My web2ldap also does this since many years to provoke write conflicts if users modified the same entry. And yes, it looks into subschema to determine whether the attributes have EQUALITY matching rule defined.
Note before your next answer: ;-) Not every LDAP server supports assertion control or MOD_INCREMENT with read entry controls. Or even worse, some implementations of the assertion control are buggy...
Ciao, Michael.
https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #12 from Howard Chu hyc@openldap.org --- (In reply to Michael Ströder from comment #11)
On 5/29/21 11:46 AM, openldap-its@openldap.org wrote:
https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #10 from Ondřej Kuzník ondra@mistotebe.net --- On Fri, May 28, 2021 at 10:20:59PM +0000, openldap-its@openldap.org wrote:
The way we munge the inbound op can backfire on operations like this:
add: singlevalued singlevalued: new - delete: singlevalued singlevalued: oldArguably, applications that do this are strange, but the protocol allows this and it's accepted on the provider.
Note that it's not strange at all: This is the recommended client behaviour when using an ID pool entry for unique ID assignment.
I'm not sure what the difference is to just sending a delete, then add from application's point of view? I know it shouldn't matter as the entry only needs to be consistent/valid when the operation is finished, but you're saying there are reasons to do just this...
Deleting certain attribute values makes sure that the entry you're modifying still has its former state. So this uses the ACID properties of a single modify operation as a test-and-set operation.
Most common example is ID assignment with an ID pool entry. You want to make sure that no other LDAP client consumed the next ID in between your last read and current ID update attempt.
My web2ldap also does this since many years to provoke write conflicts if users modified the same entry. And yes, it looks into subschema to determine whether the attributes have EQUALITY matching rule defined.
What you're describing is indeed routine. But the usual sequence is for the delete to come before the add. Even though it should make no difference in the end, it is unusual to do the add before the delete.
https://bugs.openldap.org/show_bug.cgi?id=9295
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Resolution|TEST |FIXED
-
openldap-its＠openldap.org