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. > > +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? 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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
