Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/47553 The current ACI implementation is somewhat limited with the way it handles MODRDN operations where newsuperior is used. For example, consider the case where you want to move an entry as follows: uid=tuser,ou=ou1,dc=example,dc=com -> uid=tuser,ou=ou2,dc=example,dc=com To allow someone to perform this operation, they need the "add" permission on "ou=ou2,dc=example,dc=com". This permission would also allow one to add a brand new entry to "ou=ou2,dc=example,dc=com". Certain use cases might want to allow a user to move an entry into a particular portion of the tree, but disallow adding a new entry. We could extend the ACI code to have a new permission for move operations that is separate from the "add" permission. This permission would mean that the target could be used as the destination for a move operation. In addition, it would be nice to be able to control the source for a move operation in ACIs. This would allow one to have an ACI that says "Allow user X to move entries from ou=1 to ou=2". This would likely require a new ACI keyword to specify the source (or multiple sources) for the operation. The destination could likely just use the ACI target.
Opening this bug for 7.1.z. Note: this fix is already in 7.2 as a rebase. The test cases are in upstream: ticket47553_ger.py, ticket47553_rdn_write_test.py, ticket47553_single_aci_test.py
(In reply to Noriko Hosoi from comment #1) > Opening this bug for 7.1.z. > > Note: this fix is already in 7.2 as a rebase. > > The test cases are in upstream: > ticket47553_ger.py, ticket47553_rdn_write_test.py, > ticket47553_single_aci_test.py Not sure it exists an upstream test case for the specific patch that is missing. Here is details to reproduce the problem addressed by this patch Creates 2 containers A and B, also add an entry in A container Create a user U (with password) and grant U the rights 'all' on A and B. Bound as U, try MODRDN of then entry from A to B. Without the patch it should fail 'insufficient rights'. Adding 'moddn' right make it run successfully WIth the patch, 'all' right is enough to make it successful
Builed tested: 389-ds-base-1.3.4.0-14.el7.x86_64 Verification Steps: 1) Create two containers: ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 dn: ou=test_ou_1,dc=example,dc=com changetype: add objectclass: top objectclass: organizationalunit ou: test_ou_1 adding new entry "ou=test_ou_1,dc=example,dc=com" dn: ou=test_ou_2,dc=example,dc=com changetype: add objectclass: top objectclass: organizationalunit ou: test_ou_2 adding new entry "ou=test_ou_2,dc=example,dc=com" 2) Create a user within "ou=test_ou_1,dc=example,dc=com": ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 dn: cn=test_user,ou=test_ou_1,dc=example,dc=com changetype: add objectclass: top objectclass: person cn: test_user sn: test_user adding new entry "cn=test_user,ou=test_ou_1,dc=example,dc=com" 3) Add an aci with a rule "cn=test_user is allowed all" within these containers: ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 dn: ou=test_ou_1,dc=example,dc=com changetype: modify add: aci aci: (targetattr="*")(version 3.0; acl "All rights on the ou=test_ou_1,dc=example,dc=com"; allow (all) userdn="ldap:///cn=test_user,ou=test_ou_1,dc=example,dc=com";) modifying entry "ou=test_ou_1,dc=example,dc=com" dn: ou=test_ou_2,dc=example,dc=com changetype: modify add: aci aci: (targetattr="*")(version 3.0; acl "All rights on the ou=test_ou_2,dc=example,dc=com"; allow (all) userdn="ldap:///cn=test_user,ou=test_ou_1,dc=example,dc=com";) modifying entry "ou=test_ou_2,dc=example,dc=com" 4) Run MODRDN operation on the "cn=test_user" and set "newsuperior" to the "ou=test_ou_2,dc=example,dc=com": ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 dn: cn=test_user,ou=test_ou_1,dc=example,dc=com changetype: modrdn newrdn: cn=test_user deleteoldrdn: 1 newsuperior: ou=test_ou_2,dc=example,dc=com modifying rdn of entry "cn=test_user,ou=test_ou_1,dc=example,dc=com" 5) Check everything is alright: ldapsearch -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b ou=test_ou_1,dc=example,dc=com "(objectclass=*)" # test_ou_1, example.com dn: ou=test_ou_1,dc=example,dc=com objectClass: top objectClass: organizationalunit ou: test_ou_1 ldapsearch -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b ou=test_ou_2,dc=example,dc=com "(objectclass=*)" # test_ou_2, example.com dn: ou=test_ou_2,dc=example,dc=com objectClass: top objectClass: organizationalunit ou: test_ou_2 # test_user, test_ou_2, example.com dn: cn=test_user,ou=test_ou_2,dc=example,dc=com objectClass: top objectClass: person sn: test_user cn: test_user Marking as VERIFIED.
There is copy-paste typo in the Comment 4 Under: 4) Run MODRDN operation on the "cn=test_user" and set "newsuperior" to the "ou=test_ou_2,dc=example,dc=com": Instead of 'ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -w Secret123', should be 'ldapmodify -h localhost -p 389 -D "ou=test_ou_2,dc=example,dc=com" -w Secret123'
There is copy-paste typo in the Comment 7 Instead of 'ldapmodify -h localhost -p 389 -D "ou=test_ou_2,dc=example,dc=com" -w Secret123' should be 'ldapmodify -h localhost -p 389 -D "cn=test_user,ou=test_ou_1,dc=example,dc=com" -w Secret123' Sorry for the mess.
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. https://rhn.redhat.com/errata/RHBA-2015-2351.html