[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