On Sat, 20 Sep 2014 15:39:48 -0400
Nathaniel McCallum <npmccal...@redhat.com> wrote:
> 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.
> > 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
> Are either of these possible? Is there another option?
I think the only option would be to intercept modifications on
replicas, check that the mod is due to a replication event and
discard/change the delete and change the add into a replace. This means
replay attacks will still be possible, but there is no way around that
until we handle the replication/quorum thing ourselves.
Simo Sorce * Red Hat, Inc * New York
Freeipa-devel mailing list