Bug 735114 - renaming a managed entry does not update mepmanagedby
Summary: renaming a managed entry does not update mepmanagedby
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Server - Plugins
Version: 1.2.9
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: 690318 389_1.2.9 736137
TreeView+ depends on / blocked
 
Reported: 2011-09-01 14:18 UTC by Rob Crittenden
Modified: 2015-12-10 18:41 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 736137 (view as bug list)
Environment:
Last Closed: 2015-12-10 18:41:23 UTC


Attachments (Terms of Use)
Patch (6.20 KB, patch)
2011-09-06 18:10 UTC, Nathan Kinder
nhosoi: review+
Details | Diff

Description Rob Crittenden 2011-09-01 14:18:37 UTC
Description of problem:

Renaming an entry does not change the mepmanagedby in the managed entry.

$ kinit admin

$ ipa user-add --first=John --last=Adams jadams
-------------------
Added user "jadams"
-------------------
  User login: jadams
  First name: John
  Last name: Adams
  Full name: John Adams
  Display name: John Adams
  Initials: JA
  Home directory: /home/jadams
  GECOS field: John Adams
  Login shell: /bin/sh
  Kerberos principal: jadams@example.COM
  UID: 503800184
  GID: 503800184
  Keytab: False
  Password: False

$ ipa user-show --all jadams
  dn: uid=jadams,cn=users,cn=accounts,dc=example,dc=com
  User login: jadams
  First name: John
  Last name: Adams
  Full name: John Adams
  Display name: John Adams
  Initials: JA
  Home directory: /home/jadams
  GECOS field: John Adams
  Login shell: /bin/sh
  Kerberos principal: jadams@example.COM
  UID: 503800184
  GID: 503800184
  Account disabled: False
  Keytab: False
  Password: False
  Member of groups: ipausers
  ipauniqueid: eac8f006-d4a3-11e0-a51b-0050562c8d82
  krbpwdpolicyreference: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com
  mepmanagedentry: cn=jadams,cn=groups,cn=accounts,dc=example,dc=com
  objectclass: top, person, organizationalperson, inetorgperson, inetuser,
               posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject,
               mepOriginEntry

$ ipa group-show --all jadams
  dn: cn=jadams,cn=groups,cn=accounts,dc=example,dc=com
  Group name: jadams
  Description: User private group for jadams
  GID: 503800184
  ipauniqueid: eafaa01a-d4a3-11e0-a51b-0050562c8d82
  mepmanagedby: uid=jadams,cn=users,cn=accounts,dc=example,dc=com
  objectclass: posixgroup, ipaobject, mepManagedEntry, top

$ ipa user-mod --rename qadams jadams
----------------------
Modified user "jadams"
----------------------
  User login: qadams
  First name: John
  Last name: Adams
  Home directory: /home/jadams
  Login shell: /bin/sh
  UID: 503800184
  GID: 503800184
  Account disabled: False
  Keytab: False
  Password: False
  Member of groups: ipausers

$ ipa user-show --all qadams
  dn: uid=qadams,cn=users,cn=accounts,dc=example,dc=com
  User login: qadams
  First name: John
  Last name: Adams
  Full name: John Adams
  Display name: John Adams
  Initials: JA
  Home directory: /home/jadams
  GECOS field: John Adams
  Login shell: /bin/sh
  Kerberos principal: qadams@example.COM
  UID: 503800184
  GID: 503800184
  Account disabled: False
  Keytab: False
  Password: False
  Member of groups: ipausers
  ipauniqueid: eac8f006-d4a3-11e0-a51b-0050562c8d82
  krbpwdpolicyreference: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com
  mepmanagedentry: cn=qadams,cn=groups,cn=accounts,dc=example,dc=com
  objectclass: top, person, organizationalperson, inetorgperson, inetuser,
               posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject,
               mepOriginEntry

$ ipa group-show --all qadams
  dn: cn=qadams,cn=groups,cn=accounts,dc=example,dc=com
  Group name: qadams
  Description: User private group for qadams
  GID: 503800184
  ipauniqueid: eafaa01a-d4a3-11e0-a51b-0050562c8d82
  mepmanagedby: uid=jadams,cn=users,cn=accounts,dc=example,dc=com <=====
  objectclass: posixgroup, ipaobject, mepManagedEntry, top

Note that mepmanagedby is still pointing to jadams, a non-existent entry.

The rename looked like this in LDAP:

[01/Sep/2011:10:09:23 -0400] conn=5021 op=3 MODRDN dn="uid=jadams,cn=users,cn=accounts,dc=example,dc=com" newrdn="uid=qadams" newsuperior="(null)"
[01/Sep/2011:10:09:23 -0400] conn=5021 op=3 RESULT err=0 tag=109 nentries=0 etime=0 csn=4e5f9214000000040000

Version-Release number of selected component (if applicable):

389-ds-base-1.2.9.7-1.fc15.x86_64

Comment 1 Nathan Kinder 2011-09-01 15:25:08 UTC
This sounds familiar.  I sem to remember some plugin interaction/ordering issue with the ipa-modrdn plugin.  Do you have nsslapd-pluginPrecedence set for managed entry plugin or the ipa-modrdn plugin?

Comment 2 Rob Crittenden 2011-09-01 15:46:59 UTC
The ipa-modrdn plugin has a precedence of 60.

Comment 3 Nathan Kinder 2011-09-02 21:13:46 UTC
The problem is that the plug-in precedence for the ipa-modrdn plug-in is not set in the correct entry.  Currently, you have this:

-----------------------------------------------------------------
dn: cn=Kerberos Principal Name,cn=IPA MODRDN,cn=plugins,cn=config
...
nsslapd-pluginprecedence: 60
-----------------------------------------------------------------

This is not the main plug-in config entry that ns-slapd uses for loading a plug-in.  It is instead an internal config entry used by the ipa-modrdn plug-in itself.  You need to set the precedence like this instead:

-----------------------------------------------------------------
dn: cn=IPA MODRDN,cn=plugins,cn=config
...
nsslapd-pluginprecedence: 60
-----------------------------------------------------------------

Comment 4 Nathan Kinder 2011-09-02 21:48:00 UTC
In addition to the precedence issue, there is still something else causing the mepManagedBy attribute to not be updated.  I'm still looking into the exact cause.

Comment 5 Nathan Kinder 2011-09-02 22:19:24 UTC
It looks like there's an odd plug-in interaction issue causing some issues here.  I attempted to catch the managed entry plug-in post-op processing of the MODRDN of the user in a debugger, but was surprised to see that the rename of the group entry occurred first.  Here is the stack trace:

-------------------------------------------------------------------------------
(gdb) bt
#0  mep_modrdn_post_op (pb=0x7f406801b320) at ../ds/ldap/servers/plugins/mep/mep.c:2540
#1  0x00007f40b0da851c in plugin_call_func (list=0x941ed0, operation=522, pb=0x7f406801b320,
    call_one=0) at ../ds/ldap/servers/slapd/plugin.c:1439
#2  0x00007f40b0da83ee in plugin_call_list (list=0x95ac10, operation=522, pb=0x7f406801b320)
    at ../ds/ldap/servers/slapd/plugin.c:1401
#3  0x00007f40b0da68be in plugin_call_plugins (pb=0x7f406801b320, whichfunction=522)
    at ../ds/ldap/servers/slapd/plugin.c:383
#4  0x00007f40b0d9985c in op_shared_rename (pb=0x7f406801b320, passin_args=0)
    at ../ds/ldap/servers/slapd/modrdn.c:683
#5  0x00007f40b0d98db3 in rename_internal_pb (pb=0x7f406801b320)
    at ../ds/ldap/servers/slapd/modrdn.c:407
#6  0x00007f40b0d98bec in slapi_modrdn_internal_pb (pb=0x7f406801b320)
    at ../ds/ldap/servers/slapd/modrdn.c:352
#7  0x00007f40a9a35719 in mep_rename_managed_entry (origin=0x7f4068016130,
    new_dn=0x7f40680056e0 "cn=luser,cn=groups,cn=accounts,dc=example,dc=com",
    old_dn=0x7f406800a260 "cn=tuser,cn=groups,cn=accounts,dc=example,dc=com")
    at ../ds/ldap/servers/plugins/mep/mep.c:1308
#8  0x00007f40a9a36ff9 in mep_mod_post_op (pb=0x7f406800f430)
    at ../ds/ldap/servers/plugins/mep/mep.c:2160
#9  0x00007f40b0da851c in plugin_call_func (list=0x941ed0, operation=521, pb=0x7f406800f430,
    call_one=0) at ../ds/ldap/servers/slapd/plugin.c:1439
#10 0x00007f40b0da83ee in plugin_call_list (list=0x95ac10, operation=521, pb=0x7f406800f430)
    at ../ds/ldap/servers/slapd/plugin.c:1401
#11 0x00007f40b0da68be in plugin_call_plugins (pb=0x7f406800f430, whichfunction=521)
    at ../ds/ldap/servers/slapd/plugin.c:383
#12 0x00007f40b0d971dd in op_shared_modify (pb=0x7f406800f430, pw_change=0, old_pw=0x0)
    at ../ds/ldap/servers/slapd/modify.c:946
#13 0x00007f40b0d9634e in modify_internal_pb (pb=0x7f406800f430)
    at ../ds/ldap/servers/slapd/modify.c:562
#14 0x00007f40b0d96038 in slapi_modify_internal_pb (pb=0x7f406800f430)
    at ../ds/ldap/servers/slapd/modify.c:451
#15 0x00007f40a982e438 in memberof_fix_memberof_callback (e=0x7f4068011b00,
    callback_data=0x7f4096fee380) at ../ds/ldap/servers/plugins/memberof/memberof.c:2371
#16 0x00007f40a982c976 in memberof_modop_one_replace_r (pb=0x7f406800b880,
    config=0x7f4096fee380, mod_op=0,
    group_dn=0x7f40680049c0 "cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com",
    op_this=0x7f40680049c0 "cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com",
    replace_with=0x0,
    op_to=0x7f406800df00 "uid=luser,cn=users,cn=accounts,dc=example,dc=com", stack=0x0)
    at ../ds/ldap/servers/plugins/memberof/memberof.c:1261
#17 0x00007f40a982c370 in memberof_modop_one_r (pb=0x7f406800b880, config=0x7f4096fee380,
    mod_op=0, group_dn=0x7f40680049c0 "cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com",
    op_this=0x7f40680049c0 "cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com",
    op_to=0x7f406800df00 "uid=luser,cn=users,cn=accounts,dc=example,dc=com", stack=0x0)
    at ../ds/ldap/servers/plugins/memberof/memberof.c:1047
#18 0x00007f40a982c31d in memberof_modop_one (pb=0x7f406800b880, config=0x7f4096fee380,
    mod_op=0, op_this=0x7f40680049c0 "cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com",
    op_to=0x7f406800df00 "uid=luser,cn=users,cn=accounts,dc=example,dc=com")
    at ../ds/ldap/servers/plugins/memberof/memberof.c:1036
#19 0x00007f40a982cc84 in memberof_mod_smod_list (pb=0x7f406800b880, config=0x7f4096fee380,
    mod=0, group_dn=0x7f40680049c0 "cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com",
    smod=0x7f406800c740) at ../ds/ldap/servers/plugins/memberof/memberof.c:1378
#20 0x00007f40a982ccf4 in memberof_add_smod_list (pb=0x7f406800b880, config=0x7f4096fee380,
    groupdn=0x7f40680049c0 "cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com",
    smod=0x7f406800c740) at ../ds/ldap/servers/plugins/memberof/memberof.c:1398
#21 0x00007f40a982bebe in memberof_postop_modify (pb=0x7f406800b880)
    at ../ds/ldap/servers/plugins/memberof/memberof.c:830
#22 0x00007f40b0da851c in plugin_call_func (list=0x945680, operation=521, pb=0x7f406800b880,
    call_one=0) at ../ds/ldap/servers/slapd/plugin.c:1439
#23 0x00007f40b0da83ee in plugin_call_list (list=0x95ac10, operation=521, pb=0x7f406800b880)
    at ../ds/ldap/servers/slapd/plugin.c:1401
#24 0x00007f40b0da68be in plugin_call_plugins (pb=0x7f406800b880, whichfunction=521)
    at ../ds/ldap/servers/slapd/plugin.c:383
#25 0x00007f40b0d971dd in op_shared_modify (pb=0x7f406800b880, pw_change=0, old_pw=0x0)
    at ../ds/ldap/servers/slapd/modify.c:946
#26 0x00007f40b0d9634e in modify_internal_pb (pb=0x7f406800b880)
    at ../ds/ldap/servers/slapd/modify.c:562
#27 0x00007f40b0d96038 in slapi_modify_internal_pb (pb=0x7f406800b880)
    at ../ds/ldap/servers/slapd/modify.c:451
#28 0x00007f40a900249d in _do_modify (mod_pb=0x7f406800b880,
    entryDN=0x7f4068002c00 "cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com",
    mods=0x7f4068002a80) at ../ds/ldap/servers/plugins/referint/referint.c:325
#29 0x00007f40a9002e26 in _update_all_per_mod (
    entryDN=0x7f4068002c00 "cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com",
    attr=0x7f40680075d0, attrName=0x7f4068007630 "member",
    origDN=0x7f4068002120 "uid=tuser,cn=users,cn=accounts,dc=example,dc=com",
    norm_origDN=0x7f4068006bc0 "uid=tuser,cn=users,cn=accounts,dc=example,dc=com",
    newRDN=0x7f4068001680 "uid=luser", newsuperior=0x0, mod_pb=0x7f406800b880)
    at ../ds/ldap/servers/plugins/referint/referint.c:615
#30 0x00007f40a90032d7 in update_integrity (argv=0x95af20,
    origDN=0x7f4068002120 "uid=tuser,cn=users,cn=accounts,dc=example,dc=com",
    newrDN=0x7f4068001680 "uid=luser", newsuperior=0x0, logChanges=0)
    at ../ds/ldap/servers/plugins/referint/referint.c:745
#31 0x00007f40a90023e8 in referint_postop_modrdn (pb=0xaf5140)
    at ../ds/ldap/servers/plugins/referint/referint.c:285
#32 0x00007f40b0da851c in plugin_call_func (list=0x95c6f0, operation=506, pb=0xaf5140,
    call_one=0) at ../ds/ldap/servers/slapd/plugin.c:1439
#33 0x00007f40b0da83ee in plugin_call_list (list=0x95fe90, operation=506, pb=0xaf5140)
    at ../ds/ldap/servers/slapd/plugin.c:1401
#34 0x00007f40b0da68be in plugin_call_plugins (pb=0xaf5140, whichfunction=506)
    at ../ds/ldap/servers/slapd/plugin.c:383
#35 0x00007f40b0d9985c in op_shared_rename (pb=0xaf5140, passin_args=1)
    at ../ds/ldap/servers/slapd/modrdn.c:683
#36 0x00007f40b0d98a0b in do_modrdn (pb=0xaf5140) at ../ds/ldap/servers/slapd/modrdn.c:281
#37 0x0000000000413a4c in connection_dispatch_operation (conn=0x7f40a42746b0, op=0xaef3c0,
    pb=0xaf5140) at ../ds/ldap/servers/slapd/connection.c:578
#38 0x00000000004153a0 in connection_threadmain ()
    at ../ds/ldap/servers/slapd/connection.c:2328
#39 0x000000392a228553 in ?? () from /lib64/libnspr4.so
#40 0x00007f40afe69b31 in start_thread () from /lib64/libpthread.so.0
#41 0x00007f40afba7d2d in clone () from /lib64/libc.so.6
-------------------------------------------------------------------------------

What I see here is that the initial MODRDN of the user triggers the referential integrity post-op plug-in (this has a precedence of 40).  The referential integrity plug-in sees that the "member" attribute in the "cn=ipausers,cn=groups,cn=accounts,dc=example,dc=com" entry needs to be updated to reflect the new DN for the user, so it performs an internal MOD operation to update the "ipausers" group.

This internal MOD operation triggers the memberOf post-op modify callback.  This callback sees that the "member" attribute in "ipagroups" is being updated to use the new user name, so it does an internal MOD to update the "memberOf" attribute in the newly renamed user entry.

This internal MOD operation triggers the managed entry plug-in since it is updating an origin entry (the user entry).  The managed entry plug-in looks at the user entry and the associated config template and determines that the managed entry (the group) needs to be renamed to match the user entry.  This causes the managed entry plug-in to perform an internal MODRDN on the managed group entry.  The managed entry plug-in blocks anyone from doing a MODRDN of a managed entry other than itself.  The rename of the group goes through, with no action by the managed entry plug-in to update the mepManagedBy attribute (by design).

Eventually, the MODRDN of the user entry gets picked up by the managed entry plug-in.  The plug-in detects that an origin entry is being renamed.  It looks up the DN of the associated managed entry in it's "mepManagedEntry" attribute, which points to the original DN of the group (it does not know that it has been renamed already).  It then attempts to update the "mepManagedBy" attribute in the managed group entry, but it fails since it's using the old group DN.  This also has the effect of other mapped attribute updates in the managed entry being skipped.

I think we can deal with this by having the managed entry MODRDN post-op callback check if the entry pointed to by the "mepManagedEntry" attribute is not found, and then check for it using the new name.  If we find it using the new name already, we can then go ahead and update the "mepManagedBy" value and check if any mapped values need to be updated as well.

Comment 6 Rich Megginson 2011-09-02 22:41:08 UTC
/me gets a headache trying to figure out how this will work with transactions . . .

Comment 7 Nathan Kinder 2011-09-06 18:10:33 UTC
Created attachment 521730 [details]
Patch

Comment 8 Rich Megginson 2011-09-06 18:30:46 UTC
What release(s) are we going to target?  Does this need to go into 1.2.9 or can it wait for 1.2.10?

Comment 9 Nathan Kinder 2011-09-06 19:11:48 UTC
(In reply to comment #8)
> What release(s) are we going to target?  Does this need to go into 1.2.9 or can
> it wait for 1.2.10?

This needs to go into 1.2.9.

Comment 10 Nathan Kinder 2011-09-06 19:13:28 UTC
Pushed to master.  Thanks to Noriko for her review!

Counting objects: 17, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 1.80 KiB, done.
Total 9 (delta 6), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   144c607..379c164  master -> master

Comment 11 Nathan Kinder 2011-09-06 23:31:09 UTC
Pushed to 389-ds-base-1.2.9 branch:

Counting objects: 17, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 1.78 KiB, done.
Total 9 (delta 6), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   9ef5240..c827880  129-local -> 389-ds-base-1.2.9


Note You need to log in before you can comment on or make changes to this bug.