MODDN fails when entry doesn't have memberOf attribute and new DN is in the scope of memberOfExcludeSubtree

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/48012

• Created at 2015-01-28 06:58:43 by nhosoi (@nhosoi)
• Closed as Duplicate
• Assigned to nobody
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1171663

---

Description of problem:
MODDN fails when entry doesn't have memberOf attribute and new DN is in the
scope of memberOfExcludeSubtree
I see the following error message in the errors log:
> [20/Nov/2014:00:16:35 +0100] memberof-plugin - memberof_postop_modrdn -
delete dn callback failed for
(uid=user1,ou=Deleted,ou=People,dc=example,dc=com), error (16)

How reproducible:
always

Steps to Reproduce:
1. make a fresh install of DS

2. enable memberOf plugin:
$ ldapmodify -v -h localhost:389 ... << EOF
dn: cn=MemberOf Plugin,cn=plugins,cn=config
changetype: modify
add: memberofallbackends
memberofallbackends: on
-
replace: memberofgroupattr
memberofgroupattr: member
memberofgroupattr: uniqueMember
-
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
-
EOF

3. create test entries:
$ ldapmodify -v -h localhost:389 ... << EOF
dn: ou=Deleted,ou=People,dc=example,dc=com
changetype: add
objectClass: top
objectClass: organizationalunit
ou: Deleted

dn: cn=group0,ou=Groups,dc=example,dc=com
changetype: add
objectClass: top
objectClass: groupOfUniqueNames
cn: group0

dn: uid=user0,ou=People,dc=example,dc=com
changetype: add
uid: user0
objectClass: inetUser
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
objectClass: person
cn: user0
sn: user0

dn: uid=user1,ou=People,dc=example,dc=com
changetype: add
uid: user1
objectClass: inetUser
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
objectClass: person
cn: user1
sn: user1
EOF

4. configure scope of the memberOf plugin to include suffix and exclude
ou=Deleted
$ ldapmodify -v -h localhost:389 ... << EOF
dn: cn=MemberOf Plugin,cn=plugins,cn=config
changetype: modify
add: memberofentryscope
memberofentryscope: dc=example,dc=com
-
add: memberofentryscopeexcludesubtree
memberofentryscopeexcludesubtree: ou=Deleted,ou=People,dc=example,dc=com
EOF

5. restart the server
$ sudo systemctl restart dirsrv.target

6. add user0 to group0
$ ldapmodify -v -h localhost:389 ... << EOF
dn: cn=group0,ou=Groups,dc=example,dc=com
changetype: modify
add: uniqueMember
uniqueMember: uid=user0,ou=people,dc=example,dc=com
EOF

7. check that user0 has memberOf attribute and user1 doesn't:
$ ldapsearch -h localhost:389 ... -b dc=example,dc=com  -LLL  "(uid=user*)" memberOf
dn: uid=user0,ou=People,dc=example,dc=com
memberOf: cn=group0,ou=Groups,dc=example,dc=com

dn: uid=user1,ou=People,dc=example,dc=com

8. MODDN user0 and user1 to ou=Deleted:
$ ldapmodify -v -h localhost:389 ... << EOF
dn: uid=user0,ou=People,dc=example,dc=com
changetype: moddn
newrdn: uid=user0
deleteoldrdn: 1
newsuperior: ou=Deleted,ou=People,dc=example,dc=com
EOF
ldap_initialize( ldap://localhost:389 )
modifying rdn of entry "uid=user0,ou=People,dc=example,dc=com"
        new RDN: "uid=user0" (do not keep existing values)
rename complete

$ ldapmodify -v -h localhost:389 ... << EOF
dn: uid=user1,ou=People,dc=example,dc=com
changetype: moddn
newrdn: uid=user1
deleteoldrdn: 1
newsuperior: ou=Deleted,ou=People,dc=example,dc=com
EOF
ldap_initialize( ldap://localhost:389 )
modifying rdn of entry "uid=user1,ou=People,dc=example,dc=com"
        new RDN: "uid=user1" (do not keep existing values)
ldap_rename: No such attribute (16)

9. check for memberOf attribute:
$ ldapsearch -h localhost:389 ... -b dc=example,dc=com  -LLL "(uid=user*)" memberOf
dn: uid=user0,ou=Deleted,ou=People,dc=example,dc=com

dn: uid=user1,ou=Deleted,ou=People,dc=example,dc=com

It was successfully stripped from user0.

10. restart the server

11. search for user0 and user0 again:
ldapsearch -h localhost:389 ... -b dc=example,dc=com  -LLL  "(uid=user*)" dn
dn: uid=user0,ou=Deleted,ou=People,dc=example,dc=com

dn: uid=user1,ou=People,dc=example,dc=com

Looks like the transaction of MODDN of user1 was aborted.

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2015-03-07 00:26:33

Related to 47829 & 47833.

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2015-06-15 20:31:27

I can not reproduce this issue on Master. I believe the fix for https://fedorahosted.org/389/ticket/47526 fixed this ticket as well.

Noriko, if you agree we may close it as duplicate of 47526

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2015-06-15 21:30:22

Replying to [comment:4 tbordaz]:

I can not reproduce this issue on Master. I believe the fix for https://fedorahosted.org/389/ticket/47526 fixed this ticket as well.

Noriko, if you agree we may close it as duplicate of 47526

Yes! Thanks for verifying the fix, Thierry. Please close this ticket as a dup.
Thanks!

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2015-06-16 17:30:17

attachment
ticket47833_test.py

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2015-06-16 17:32:38

Attaching the test case of https://fedorahosted.org/389/ticket/47833, as it is the same problem.
Now this ticket 48012 being fixed by 47526, I close it as dup of 47526

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2017-02-11 22:47:55

Metadata Update from @tbordaz:

• Issue set to the milestone: 1.3.4 backlog