[Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin
thierry bordaz
tbordaz at redhat.com
Wed Sep 17 13:33:23 UTC 2014
On 09/15/2014 09:05 PM, Nathaniel McCallum wrote:
> This plugin ensures that all counter/watermark operations are atomic
> and never decrement. Also, deletion is not permitted.
>
> https://fedorahosted.org/freeipa/ticket/4494
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
Hello Nathaniel,
More thoughts.. I think being "betxnpreoperation" you are safe with
parallel client ops and the check is atomic. I have few comments:
* Shouldn't be implemented
SLAPI_PLUGIN_CLOSE_FN/SLAPI_PLUGIN_START_FN callback, even if
they are empty.
* In load_counters, in case we have a target entry that has not
'objectclass' 'ipatokenHOTP|ipatokenTOTP' and the mod operation:
dn: <entry>
changetype: modify
replace: ipatokenHOTPcounter
ipatokenHOTPcounter: 200
-
add: objectclass
objectclass: ipatokenHOTP
I wonder if the operation will not fail although IMHO it should
succeeds.
Shouldn't let the schema checking reject the operation if the
attribute is not granted by the entry objectclass
* in load_counters, I am under the impression it may return
ipatokenHOTPcounter or ipatokenTOTPwatermark
(ipatokenHOTPcounter is missing).
But then how the caller knows that the returned value is a
counter or a watermark ?
* in ldapmod_is_attrs you may prefer PL_strcasecmp to strcasecmp
About replicated updates, if updates of counters/watermark are done
on several servers. Then a replicated operation may want to set
counters/watermark with a smaller value that the existing one. In
that case, it will return unwilling to perform. That could break
replication.
If the update comes from replication and the value is going
backward, we could make the operation a nop operation (setting the
attribute to its current value).
thanks
theirry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140917/3dfb7268/attachment.htm>
More information about the Freeipa-devel
mailing list