Red Hat Bugzilla – Bug 860772
Change on SLAPI_MODRDN_NEWSUPERIOR is not evaluated in acl
Last modified: 2013-06-24 06:49:36 EDT
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/340 plugin_acl.c /* This function is now fully executed for internal and replicated ops. */ int plugin_call_acl_mods_update ( Slapi_PBlock *pb, int optype ) case SLAPI_OPERATION_MODRDN: /* newrdn: "change" is normalized but not case-ignored */ /* The acl plugin expects normalized newrdn, but no need to be case- * ignored. */ (void)slapi_pblock_get( pb, SLAPI_MODRDN_NEWRDN, &change ); break; Bug description: The change on SLAPI_MODRDN_NEWSUPERIOR is not evaluated in acl. There may be other places in the code where there is an implicit assumption that modrdn with new superior is not supported.
Cherry picked 5beb93d42efb807838c09c5fab898876876f8d09. Pushed to external 389-ds-base-1.2.11. $ git push origin 389-ds-base-1.2.11-ext:389-ds-base-1.2.11 Counting objects: 25, done. Delta compression using up to 4 threads. Compressing objects: 100% (13/13), done. Writing objects: 100% (13/13), 2.55 KiB, done. Total 13 (delta 11), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git cf42a2f..7399cbd 389-ds-base-1.2.11-ext -> 389-ds-base-1.2.11
QA acked.
acl modrdn suite: modrdn Test trac340: test for renaming target entry Create a test user entry adding new entry uid=trac340,o=ace industry,c=us Create a new ou entry with an aci adding new entry ou=OU0,o=ace industry,c=us Make sure uid=trac340 has the access dn: ou=OU0,o=ace industry,c=us OK: uid=trac340 has the access. Rename ou=OU0 to ou=OU1 modifying RDN of entry ou=OU0,o=ace industry,c=us Make sure uid=trac340 still has the access dn: ou=OU1,o=ace industry,c=us OK: uid=trac340 has the access. Create another ou=OU2 adding new entry ou=OU2,o=ace industry,c=us Move ou=OU1 under ou=OU2 modifying RDN of entry ou=OU1,o=ace industry,c=us and/or moving it beneath a new parent Make sure uid=trac340 still has the access dn: ou=OU1,ou=OU2,o=ace industry,c=us OK: uid=trac340 has the access. Clean up the test entries ldap_delete: No such object TestCase [trac340] result-> [PASS] $ rpm -qa 389-ds-base 389-ds-base-1.2.11.15-11 Verified.
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/RHSA-2013-0503.html
Covered in acl modrdn suite