[Freeipa-devel] ipapwd_extop vs password_extop

[thierry bordaz]

On 06/06/2016 07:12 PM, Alexander Bokovoy wrote:
> On Mon, 06 Jun 2016, thierry bordaz wrote:
>>
>>
>> On 06/06/2016 11:07 AM, Alexander Bokovoy wrote:
>>> On Mon, 06 Jun 2016, thierry bordaz wrote:
>>>> Hello,
>>>>
>>>>  In DS it is possible to register callbacks for extended op.
>>>>  For https://www.ietf.org/rfc/rfc3062.txt (password modify extop),
>>>>  there is a default callback that is implemented in DS core server.
>>>>  Freeipa enables a plugin 'cn=ipa_pwd_extop,cn=plugins,cn=config'
>>>>  that also register a callback ipapwd_extop/ipapwd_chpwop, for that
>>>>  same extop.
>>>>
>>>>  The server calls the callbacks until it can find one that can handle
>>>>  the OID. But the order is not guaranty.
>>>>  So the extop can be handled either by password_extop or either by
>>>>  ipapwd_chpwop.
>>>>
>>>>  Those two functions are not doing the same checking/updates.
>>>>
>>>>  I would like to confirm if in Freeipa context, if only
>>>>  ipapwd_extop/ipapwd_chpwop should be called
>>> Correct. I think we have also added plugin priority to allow handling
>>> this type of conflicts gracefully.
>>>
>>
>>
>> The order of the plugins, is based on nsslapd-pluginprecedence.
>> (The lower precedence is called first)
>>
>> The problem is that ipapw_extop and password_extop have the same 
>> precedence: 50. So the order they are selected basically rely on 
>> order they were registered.
>> "Password Modify extended operation plugin" (core server) is 
>> registered before "IPA Password Extended Operation plugin".
>> I think we need  to add a precedence of "IPA Password Extended 
>> Operation plugin" to be sure it will be selected over "Password 
>> Modify extended operation plugin"
>>
>> In addition https://fedorahosted.org/389/ticket/48770 changed the way 
>> plugins are selected so even setting a precedence is currently not a 
>> solution (I opened https://fedorahosted.org/389/ticket/48870)
>>
>> In short we need to fix https://fedorahosted.org/389/ticket/48870
>>
>>
>> Regarding item 5.4, replacing a compat entry with its related real 
>> entry.
>> I think there is something missing.  In fact the extop is doing an 
>> internal MOD but before calling the MOD it checks the entry exists. 
>> And if called against a 'compat' entry the extop fails before calling 
>> the MOD.
>> But even if it was successfull it may be not be a good idea to make 
>> 'Schema Compat' preop-mod doing the mapping 'compat' -> real for all 
>> MODS.
> given that schema compat is read-only (always), you can do remapping all
> the time. We have this mapping already for password checks, how is this
> different?
It should be similar to mapping done for password check. When is it 
triggered or where is the code for this mapping ?
>
>> A option is to change "IPA Password Extended Operation plugin" to do 
>> this mapping 'compat' -> 'real' but it is looking like a hack.
> Yes, it is unacceptable.
>
Well here we have IPA password extop that receives a 'compat' entry. 
This compat entry does not exist except in slapi-nis that can do the 
mapping to the real entry. What I was thinking of was some kind of call 
from IPA password extop to slapi-nis that for a given entry DN return 
the real entryDN. But the tranformation of the extop('compat') -> 
extop('real') would be done in IPA password extop