Bug 736137

Summary: renaming a managed entry does not update mepmanagedby
Product: Red Hat Enterprise Linux 6 Reporter: Nathan Kinder <nkinder>
Component: 389-ds-baseAssignee: Rich Megginson <rmeggins>
Status: CLOSED ERRATA QA Contact: Chandrasekar Kannan <ckannan>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 6.2CC: benl, edewata, jgalipea, nhosoi, nkinder, rcritten, rmeggins
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.2.9.10-1.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 735114 Environment:
Last Closed: 2011-12-06 17:56:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 735114    
Bug Blocks: 690318, 708096    

Description Nathan Kinder 2011-09-06 19:15:11 UTC 
+++ This bug was initially created as a clone of Bug #735114 +++

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
  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
  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
  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

--- Additional comment from nkinder on 2011-09-01 11:25:08 EDT ---

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?

--- Additional comment from rcritten on 2011-09-01 11:46:59 EDT ---

The ipa-modrdn plugin has a precedence of 60.

--- Additional comment from nkinder on 2011-09-02 17:13:46 EDT ---

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
-----------------------------------------------------------------

--- Additional comment from nkinder on 2011-09-02 17:48:00 EDT ---

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.

--- Additional comment from nkinder on 2011-09-02 18:19:24 EDT ---

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.

--- Additional comment from rmeggins on 2011-09-02 18:41:08 EDT ---

/me gets a headache trying to figure out how this will work with transactions . . .

--- Additional comment from nkinder on 2011-09-06 14:10:33 EDT ---

Created attachment 521730 [details]
Patch

--- Additional comment from rmeggins on 2011-09-06 14:30:46 EDT ---

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?

--- Additional comment from nkinder on 2011-09-06 15:11:48 EDT ---

(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.

--- Additional comment from nkinder on 2011-09-06 15:13:28 EDT ---

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 1 Nathan Kinder 2011-09-06 19:16:22 UTC 
This is needed for IPA in RHEL 6.2, as it breaks user private group updates.
Comment 2 Nathan Kinder 2011-09-06 23:31:45 UTC 
Pushed to internal RHEL-6 branch:

nkinder.redhat.com's password: 
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.engineering.redhat.com/srv/git/users/rmeggins/ds.git
   00032d0..c7861eb  RHEL-6 -> RHEL-6
Comment 4 Jenny Severance 2011-09-27 18:28:40 UTC 
verified

version:
389-ds-base-1.2.9.11-1.el6.x86_64
ipa-server-2.1.1-4.el6.x86_64

# 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: 1426400019
  GID: 1426400019
  Account disabled: False
  Keytab: False
  Password: False
  Member of groups: ipausers

# ipa user-show --all qadams
  dn: uid=qadams,cn=users,cn=accounts,dc=testrelm
  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@TESTRELM
  UID: 1426400019
  GID: 1426400019
  Account disabled: False
  Keytab: False
  Password: False
  Member of groups: ipausers
  ipauniqueid: 2999fe96-e936-11e0-b8b4-5254008a96bf
  krbpwdpolicyreference: cn=global_policy,cn=TESTRELM,cn=kerberos,dc=testrelm
  mepmanagedentry: cn=qadams,cn=groups,cn=accounts,dc=testrelm
  objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux,
               krbticketpolicyaux, ipaobject, mepOriginEntry

# ipa group-show --all qadams
  dn: cn=qadams,cn=groups,cn=accounts,dc=testrelm
  Group name: qadams
  Description: User private group for qadams
  GID: 1426400019
  ipauniqueid: 29b99ef4-e936-11e0-b8b4-5254008a96bf
  mepmanagedby: uid=qadams,cn=users,cn=accounts,dc=testrelm
  objectclass: posixgroup, ipaobject, mepManagedEntry, top
Comment 5 errata-xmlrpc 2011-12-06 17:56:27 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2011-1711.html