On Tue, 07 Jun 2016, thierry bordaz wrote:

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:

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

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
It should be similar to mapping done for password check. When is it triggered or where is the code for this mapping ?
See slapi-nis/src/back-sch.c:backend_bind_cb() for details.

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
no, just look at slapi-nis code to see how we rewrite DN of the request.
You'd need to do a similar trick.

/ Alexander Bokovoy

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to