On 06/07/2016 01:20 PM, Alexander Bokovoy wrote:
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:
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 ?
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.
Thanks for the pointer. What differs is that slapi-nis is doing the
mapping in an operation (here bind) preop.
But with extop there is no preop call. Mapping looks to be done in
backend_locate, my understanding is that we need to find a way to call
something like backend_locate from extop and it can not be done with an
internal search because slapi-nis ignores them.
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
