Hide Forgot
Description of problem: A permission that specifies a filter, is disregarded, when a user is assigned that permission. 1> Add a permission: ipa permission-add "ManageGroup" --filter='(&(!(objectclass=posixgroup))(objectclass=ipausergroup))'--permissions=write 2> Add privilege with just this one permission. 3> Add role with just the above privilege 4> Add user and assigned the role above 5> Add a group and uncheck "Is this a POSIX group" 6> kinit as this user 7> Update the group's description, and an error is thrown about having insufficient access Expected this user to be able to update the above added group's description, or add other users as members of this group. Doc says: --filter uses an LDAP filter to identify which entries the permission applies to. All attributes within the matching entries can be modified. tried another filter - ipa permission-add "ManageGroup" --filter='(givenname=xyz)' --permissions=write and expected the kinit'd user with this permission to be able to change attributes for user with givenname=xyz, but this user is displayed (in UI) as readonly, and no attributes can be modified. Version-Release number of selected component (if applicable): ipa-server-2.2.0-101.20120117T0229zgit5febffb.el6.x86_64 How reproducible: always Steps to Reproduce: 1. as indicated above Actual results: an error is thrown about having insufficient access Expected results: Expected this user to be able to update the above added group's description, or add other users as members of this group. Additional info:
Upstream ticket: https://fedorahosted.org/freeipa/ticket/2294
Same behaviour seen when using subtree. Added a permission: ipa permission-add ManageHost --permissions="write" --subtree=cn=computers,cn=accounts,dc=testrelm,dc=com login as a user whose role includes this perm, and can only edit desc, kerberos key, otp, and host cert (cannot update successfully) but still these are the only fields available. Locality, location, platform and OS are not allowed to be edited by this user. Should be able to edit "all" attributes
Based on Rich's explanation in bug 784315, "in an aci, if you do not specify a targetattr clause, the default is no access to any attribute" And so I was seeing the behaviour above. I can specify attr in CLI when using filter, but UI doesn't allow attr to be specified, when using filter or subtree.
Fixed in upstream: https://fedorahosted.org/freeipa/ticket/2372 Master: 885ffe5a3e2ef4d370c4fffa458ef44fd61c5250 37cdbae23424b0dd8c6296d0303efdfa3bfffcfd ipa2-2: c34b1a31a476efc468a0332a0576e96a6acffcb8 0ec8b421ec8f2dfa4572f3d3253a0888c58c6fb0
Just a small clarification - Ticket 2294 was closed upstream as well as a duplicate of Ticket 2372.
Using ipa-server-2.2.0-7.el6.x86_64 In UI, can add Permission with Target chosen to be Filter, and this allows to "Add" attributes. But with Target chosen to be Subtree, still cannot "Add" attribute. CLI allows this: # ipa permission-add ManageHost1 --permissions="write" --subtree=cn=computers,cn=accounts,dc=testrelm,dc=com --attr=nshostlocation --memberof=groupone ------------------------------ Added permission "ManageHost1" ------------------------------ Permission name: ManageHost1 Permissions: write Attributes: nshostlocation Member of group: groupone Subtree: ldap:///cn=computers,cn=accounts,dc=testrelm,dc=com Added new permission ManageHost1 successfully
Thanks for testing Namita, I will reopen upstream ticket.
There is already a special upstream ticket dealing with the issue you found, I will link the Bugzilla there: https://fedorahosted.org/freeipa/ticket/2592
Now it should be finally fixed in upstream. master: dedc7889dc0e8987cc7cc6f70a67ae571c80a10b ipa-2-2: 49ed21dee4d3c2524f633592f935ba39c5faba6a adds attrs for target=subtree. So all target types should have attrs field.
Verified using ipa-server-2.2.0-9.el6.x86_64
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No documentation needed.
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/RHBA-2012-0819.html