Bug 760687
| Summary: | 389 DS does not honor the manageDsaIT control on ldapmodify | |||
|---|---|---|---|---|
| Product: | [Retired] freeIPA | Reporter: | Stephen Gallagher <sgallagh> | |
| Component: | ipa-server | Assignee: | Rob Crittenden <rcritten> | |
| Status: | CLOSED ERRATA | QA Contact: | Chandrasekar Kannan <ckannan> | |
| Severity: | high | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 2.1 | CC: | benl, dpal, jgalipea, mkosek, msauton, nhosoi, nkinder, rcritten, rmeggins | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | freeipa-3.0.0-2.fc18 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 782554 (view as bug list) | Environment: | ||
| Last Closed: | 2012-10-16 07:16:09 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 743970, 782554 | |||
|
Description
Stephen Gallagher
2011-12-06 19:10:39 UTC
Hi Stephen,
I'm trying to follow your steps... (I'm running the test on my F15 and using my local build from git master.)
This is the original entry I added to my ldapserver.
dn: uid=keitaro,o=my.com
objectClass: top
objectClass: extensibleObject
uid: keitaro
ref: ldap://ipaserver:389/uid=kurashima,cn=users,cn=accounts,dc=referrals,dc=example,dc=com??base?
I searched it with openldap ldapsearch.
$ ldapsearch -LLLx -h localhost -p 389 -b 'o=my.com'
[...]
# refldap://ipaserver:389/uid=kurashima,cn=users,cn=accounts,dc=referrals,dc=
example,dc=com??base?
I tried to modify the referral, then I got return value 10 as you reported:
$ ldapmodify -x -h localhost -p 389 -D 'cn=directory manager' -w passwd
dn: uid=keitaro,o=my.com
changetype: modify
replace: ref
ref: ldap://ipaserver.referrals.sgallagh.bos.redhat.com:389/uid=kurashima,cn=users,cn=accounts,dc=referrals,dc=sgallagh,dc=bos,dc=redhat,dc=com??base?
modifying entry "uid=keitaro,o=my.com"
ldap_modify: Referral (10)
referrals:
ldap://ipaserver:389/uid=kurashima,cn=users,cn=accounts,dc=referrals,dc=example,dc=com??base?
Here's the snippet of the openldap ldapmodify usage:
usage: ldapmodify [options]
Add or modify options:
-M enable Manage DSA IT control (-MM to make critical)
Once you add the option to ldapmodify, the request is served.
$ ldapmodify -M -x -h localhost -p 389 -D 'cn=directory manager' -w passwd
dn: uid=keitaro,o=my.com
changetype: modify
replace: ref
ref: ldap://ipaserver.referrals.sgallagh.bos.redhat.com:389/uid=kurashima,cn=users,cn=accounts,dc=referrals,dc=sgallagh,dc=bos,dc=redhat,dc=com??base?
modifying entry "uid=keitaro,o=my.com"
Here's the search result.
$ ldapsearch -LLLx -h localhost -p 389 -b 'o=my.com'
[...]
# refldap://ipaserver.referrals.sgallagh.bos.redhat.com:389/uid=kurashima,cn=
users,cn=accounts,dc=referrals,dc=sgallagh,dc=bos,dc=redhat,dc=com??base?
Could you tell us how you specified the manageDsaIT control on ldapmodify?
Thanks,
--noriko
Noriko, I used the -M option to ldapmodify to specify the manageDsaIT control. (Sorry that I didn't put that in the bug). When that failed, I also attempted to use -e manageDSAit as an alternative approach, but got the same results as above. This was against 389-ds-base-1.2.9.13-1.el6.x86_64 (which has been configured by ipa-client-install from ipa-server-2.1.3-9.el6.x86_64 I think the problem is in op_shared_modify(), the get_entry() call at line 706:
if ( !repl_op && !internal_op && dn &&
(e = get_entry(pb, slapi_dn_normalize(dn))) )
{
get_entry() does not examine the managedsait control, so it just returns a referral.
On a side note, it would be very, very nice to move all of the special purpose password and password policy handling code to the backend and/or be pre/post op plugins . . .
Yes, get_entry does not check the ManageDsaIT, but the control is examined in the backend findentry.
static struct backentry *
find_entry_internal_dn(...)
{
[...]
/* get the managedsait ldap message control */
slapi_pblock_get( pb, SLAPI_MANAGEDSAIT, &managedsait );
while ( (tries < LDBM_CACHE_RETRY_COUNT) &&
(e = dn2entry_ext( be, sdn, txn, flags & TOMBSTONE_INCLUDED, &err ))
!= NULL )
{
/*
* we found the entry. if the managedsait control is set,
* we return the entry. if managedsait is not set, we check
* for the presence of a ref attribute, returning to the
* client a referral to the ref'ed entry if a ref is present,
* returning the entry to the caller if not.
*/
if ( !managedsait && !(flags & FE_REALLY_INTERNAL)) {
/* see if the entry is a referral */
if(check_entry_for_referral(pb, e->ep_entry, NULL, "find_entry_internal_dn"))
{
CACHE_RETURN( &inst->inst_cache, &e );
return( NULL );
}
}
For me, if -M or "-e manageDSAit" is appended to openldap ldapmodify, the "managedsait" variable gets 1 in find_entry_internal_dn, and it returns the original entry instead of following the referral... *puzzled*
I also tried with 1.2.10-0.4.a4 from 389 repo. It also works fine with "-M" or "-e manageDSAit".
389-ds-base-1.2.10-0.4.a4.fc15.x86_64
(In reply to comment #3) > On a side note, it would be very, very nice to move all of the special purpose > password and password policy handling code to the backend and/or be pre/post op > plugins . . . I agree with you. Nathan also mentioned it some time back. Shall we open a bug/ticket to work on the project? Upstream ticket: https://fedorahosted.org/389/ticket/9 Thanks to Marc for letting me use his IPA system.
I could reproduce the problem using his DS managed by IPA.
# ldapmodify -M -x -D "cn=directory manager" -w <pw> -h localhost -p 389
dn: uid=keitaro,dc=example,dc=com
changetype: modify
replace: ref
ref: ldap://ipaserver.referrals.sgallagh.bos.redhat.com:389/uid=kurashima,cn=users,cn=accounts,dc=referrals,dc=sgallagh,dc=bos,dc=redhat,dc=com??base?
modifying entry "uid=keitaro,dc=example,dc=com"
ldap_modify: Referral (10)
I stopped in check_entry_for_referral in gdb and went through the stacktrace (see below). It seems a pre-op plugin ipa_uuid returns the return code 10 to the client (ldapmodify -M, this case) without doing any further operation.
Without the plugin, we could reach the backend modify function ldbm_back_modify and the change is properly made.
I was hoping to look into the ipa_uuid plugin, but I could not find the package in brew nor koji... I guess what the ipa_uuid plugin should do is just ignoring the referral return code (10)?
rpm -qf /usr/lib64/dirsrv/plugins/libipa_uuid.so
ipa-server-2.1.3-9.el6.x86_64
#0 check_entry_for_referral (pb=0x7f66f4004250, entry=0x7f6724003b30,
matched=0x0, callingfn=0x7f672f16ead0 "find_entry_internal_dn")
at ldap/servers/slapd/back-ldbm/findentry.c:87
#1 0x00007f672f124307 in find_entry_internal_dn (pb=0x7f66f4004250,
be=0xcb4bd0, addr=<value optimized out>, lock=0, txn=0x0,
really_internal=0) at ldap/servers/slapd/back-ldbm/findentry.c:134
#2 find_entry_internal (pb=0x7f66f4004250, be=0xcb4bd0,
addr=<value optimized out>, lock=0, txn=0x0, really_internal=0)
at ldap/servers/slapd/back-ldbm/findentry.c:285
#3 0x00007f672f1563aa in ldbm_back_search (pb=0x7f66f4004250)
at ldap/servers/slapd/back-ldbm/ldbm_search.c:450
#4 0x00007f6739537e05 in op_shared_search (pb=0x7f66f4004250, send_result=1)
at ldap/servers/slapd/opshared.c:686
#5 0x00007f67395422e2 in search_internal_callback_pb (pb=0x7f66f4004250,
callback_data=<value optimized out>, prc=<value optimized out>,
psec=0x7f6739542740 <internal_plugin_search_entry_callback>,
prec=0x7f67395426e0 <internal_plugin_search_referral_callback>)
at ldap/servers/slapd/plugin_internal_op.c:761
#6 0x00007f6739542518 in search_internal_pb (pb=0x7f66f4004250)
at ldap/servers/slapd/plugin_internal_op.c:611
#7 0x00007f6739543046 in slapi_search_internal_get_entry (dn=0x7f66f4008010,
attrs=0x0, ret_entry=0x7f6708be6950, component_identity=0xc4a270)
at ldap/servers/slapd/plugin_internal_op.c:895
#8 0x00007f672fdaf2a8 in ?? () from /usr/lib64/dirsrv/plugins/libipa_uuid.so
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#9 0x00007f673953f32d in plugin_call_func (list=0xc4d7a0, operation=405,
pb=0x101c780, call_one=0) at ldap/servers/slapd/plugin.c:1439
#10 0x00007f673953f53d in plugin_call_list (pb=0x101c780, whichfunction=405)
at ldap/servers/slapd/plugin.c:1401
#11 plugin_call_plugins (pb=0x101c780, whichfunction=405)
at ldap/servers/slapd/plugin.c:383
#12 0x00007f6739531ab9 in op_shared_modify (pb=<value optimized out>,
pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:852
#13 0x00007f6739532c46 in do_modify (pb=0x101c780)
at ldap/servers/slapd/modify.c:384
#14 0x00000000004135e4 in connection_dispatch_operation ()
at ldap/servers/slapd/connection.c:583
#15 connection_threadmain () at ldap/servers/slapd/connection.c:2328
#16 0x00007f673773a6f3 in ?? () from /lib64/libnspr4.so
#17 0x00007f67370de7f1 in start_thread () from /lib64/libpthread.so.0
#18 0x00007f6736e1b70d in clone () from /lib64/libc.so.6
(In reply to comment #7) > I was hoping to look into the ipa_uuid plugin, but I could not find the package > in brew nor koji... I guess what the ipa_uuid plugin should do is just > ignoring the referral return code (10)? > I believe that the ipa_uuid plug-in is a part of the ipa-server package. (In reply to comment #8) > (In reply to comment #7) > > I was hoping to look into the ipa_uuid plugin, but I could not find the package > > in brew nor koji... I guess what the ipa_uuid plugin should do is just > > ignoring the referral return code (10)? > > > > I believe that the ipa_uuid plug-in is a part of the ipa-server package. Yeah, that's right. My problem is I searched "ipa-server" on these 2 systems, but both returns "No search results". Where can I find the debuginfo package? http://koji.fedoraproject.org/koji/ https://brewweb.devel.redhat.com/ (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > I was hoping to look into the ipa_uuid plugin, but I could not find the package > > > in brew nor koji... I guess what the ipa_uuid plugin should do is just > > > ignoring the referral return code (10)? > > > > > > > I believe that the ipa_uuid plug-in is a part of the ipa-server package. > > Yeah, that's right. My problem is I searched "ipa-server" on these 2 systems, > but both returns "No search results". Where can I find the debuginfo package? > http://koji.fedoraproject.org/koji/ http://koji.fedoraproject.org/koji/packageinfo?packageID=11554 > https://brewweb.devel.redhat.com/ https://brewweb.devel.redhat.com/packageinfo?packageID=4384 Also, the upstream repository is git://git.fedorahosted.org/git/freeipa.git Also, the specific source file you're looking for is: http://git.fedorahosted.org/git/?p=freeipa.git;a=blob;f=daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c;h=5430de4c99d9c472a1dfbf52fd5d2374d7a07380;hb=HEAD Thanks a lot, Stephen! I could get ipa-server-debuginfo!
#8 0x00007f672fdaf2a8 in ipauuid_pre_op (pb=0x101c780, modtype=4)
at ipa_uuid.c:817
817 ret = slapi_search_internal_get_entry(tmp_dn, NULL, &e, getPluginID());
(gdb) p ret
$2 = 10
818 slapi_sdn_free(&tmp_dn);
819
820 if (ret) {
821 /* ok a client tried to modify an entry that doesn't exist.
822 * Nothing to see here, move along ... */
823 goto done;
824 }
[...]
1164 done:
[...]
1190 if (ret) {
1191 LOG("operation failure [%d]\n", ret);
1193 slapi_ch_free((void **)&errstr);
1191 LOG("operation failure [%d]\n", ret);
1192 slapi_send_ldap_result(pb, ret, NULL, errstr, 0, NULL);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This line returns return code 10 to the client (ldapmodify).
Do we want not to send the result if the return code "ret" is 10?
Let me change the component to freeipa. Do I need to open a freeipa trac ticket, too? marking as screened because it has been cloned upstream(In reply to comment #13) > Let me change the component to freeipa. > Do I need to open a freeipa trac ticket, too? yes (In reply to comment #14) > marking as screened because it has been cloned upstream(In reply to comment > #13) > > Let me change the component to freeipa. > > Do I need to open a freeipa trac ticket, too? > > yes https://fedorahosted.org/freeipa/ticket/2237 Fixed upstream: master: https://fedorahosted.org/freeipa/changeset/58732a83bc4ea99ce9894f07232b890ae26682ef |