[Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin

[Nathaniel McCallum]

On Sat, 2014-09-20 at 00:25 +0200, thierry bordaz wrote:
> Hello Nathaniel,
> 
>         sanitize_input translates MOD/REPLACE into MOD/DEL+MOD/ADD. It
>         looks good but difficult to think to all possible cases.
>         I think to the following corner case:
>         The initial entry has ipatokenHOTPcounter=5
>         ldapmodify..
>         changetype: modify
>         add: ipatokenHOTPcounter
>         ipatokenHOTPcounter: 6
>         -
>         replace: ipatokenHOTPcounter
>         ipatokenHOTPcounter: 7
>         
>         It translates
>         add: 6
>         del: 5
>         add: 7
>         
>         This operation will fail because ipatokenHOTPcounter is
>         single-valued although IMHO it should succeed.

No. It should fail. There can only ever be one ipatokenHOTPcounter.

>         This is a so special operation that is may not really be a
>         concern.

+1

>         It is important that attribute are single valued. The
>         replication changelog will replicated MOD/DEL + MOD/ADD for a
>         MOD/REPL.
>         That means that if the attributes are updated on several
>         masters, the number of values can likely increase. Where for
>         single value it should only keep the most recent value.

That is a concern, at least for now. Eventually we won't use replication
for this at all. But for now, we will.

Here is the problem I foresee. You have two servers: A and B.

The user authenticates on A. This triggers a MOD/DEL(0)+MOD/ADD(1).
Replication is sent to server B.

Before the replication is performed on server B, the user authenticates
with the next token. This triggers a MOD/DEL(0)+MOD/ADD(2). Replication
is sent to server A. This replication will fail because A has a value of
1, not a value of 0.

The end result is that there will be different values for
ipatokenHOTPcounter on the two different servers. A will have 1 and B
will have 2. Once this happens, the replications can never reconcile
(this is a big problem). I see two options here, both theoretical.

Option #1 is to hook 389 in a different place: before the mods are
performed by after the replication changelog is generated.
Alternatively, we could insert a hook after the replication changelog is
generated, but before it is sent. We could consolidate the MOD/DEL
+MOD/ADD here into a single MOD/REPLACE operation.

Option #2 is to have some way to translate the MOD/REPLACE(X) into a
MOD/DEL(<=X)+MOD/ADD(X).

Are either of these possible? Is there another option?

Nathaniel