Bug 783502
Summary: | ipa permission-add does not fail if using invalid attribute | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Namita Soman <nsoman> | |
Component: | ipa | Assignee: | Rob Crittenden <rcritten> | |
Status: | CLOSED ERRATA | QA Contact: | IDM QE LIST <seceng-idm-qe-list> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 6.2 | CC: | dpal, jgalipea, mkosek, syeghiay | |
Target Milestone: | rc | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | ipa-2.2.0-12.el6 | Doc Type: | Bug Fix | |
Doc Text: |
The Identity Management permission plug-in does not verify that the set of attributes specified for a new permission is relevant to the target object type that the permission allows access to. This means a user is able to create a permission which allows access to attributes that will never be present in the target object type because such attributes are not allowed in its object classes. You must ensure that the chosen set of attributes for which a new permission grants access to is relevant to the chosen target object type.
|
Story Points: | --- | |
Clone Of: | ||||
: | 817401 (view as bug list) | Environment: | ||
Last Closed: | 2012-06-20 13:31:16 UTC | Type: | --- | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 817401 |
Description
Namita Soman
2012-01-20 16:18:56 UTC
I'm tempted to close this as not a bug. --type doesn't specify an object type so much as a container to look for objects (which in our case is always one type of object). ACIs are meant to be flexible, they are likely to be used in ways we can never imagine. Upstream ticket: https://fedorahosted.org/freeipa/ticket/2293 fixed upstream. Attributes are only checked with type is provided. master: 1356988b7a40a60af39807db143860efb4a2f435 ipa-2-2: a331f351665d32b82cab4d6c53ae9496f38ebd9e I used to be able to do the below: ipa permission-add ManageHostgroup1 --permissions="add,delete,write" --type=hostgroup --attr=businessCategory,owner ----------------------------------- Added permission "ManageHostgroup1" ----------------------------------- Permission name: ManageHostgroup1 Permissions: add, delete, write Attributes: businesscategory, owner Type: hostgroup Added new permission ManageHostgroup1 successfully But on ipa-server-2.2.0-4.el6.x86_64 - I get error: ipa permission-add ManageHostgroup1 --permissions="add,delete,write" --type=hostgroup --attr=businessCategory,owner ipa: ERROR: attribute(s) "businesscategory,owner" not allowed also tried: ipa permission-add ManageHostgroup1 --permissions="write" --type=hostgroup --attr=description ipa: ERROR: attribute(s) "description" not allowed Fixed upstream: master: https://fedorahosted.org/freeipa/changeset/a58cbb985ec007c0ef83010b32408efb2f4784d2 ipa-2-2: https://fedorahosted.org/freeipa/changeset/f0006402b85683009825bb80895852ca5dc94fa6 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. Verified using ipa-server-2.2.0-11.el6.x86_64 Executing: ipa permission-add ManageUser --permissions="read" --type=user --attr=ipaclientversion ipa: ERROR: attribute(s) "ipaclientversion" not allowed :: [09:49:53] :: There was an error adding ManageUser Will reopen this bug. It is failing for the case below: # ipa permission-show "Change a user password" --all dn: cn=change a user password,cn=permissions,cn=pbac,dc=testrelm,dc=com Permission name: Change a user password Permissions: write Attributes: userpassword, krbprincipalkey, sambalmpassword, sambantpassword, passwordhistory Type: user Filter: (!(memberOf=cn=admins,cn=groups,cn=accounts,dc=testrelm,dc=com)) Granted to Privilege: User Administrators, Modify Users and Reset passwords memberindirect: cn=user administrators,cn=privileges,cn=pbac,dc=testrelm,dc=com, cn=modify users and reset passwords,cn=privileges,cn=pbac,dc=testrelm,dc=com, cn=user administrator,cn=roles,cn=accounts,dc=testrelm,dc=com, cn=helpdesk,cn=roles,cn=accounts,dc=testrelm,dc=com objectclass: top, groupofnames, ipapermission # ipa permission-mod "Change a user password" --attrs=userpassword,krbprincipalkey,sambalmpassword,passwordhistory ipa: ERROR: attribute(s) "sambalmpassword,passwordhistory" not allowed Deleted Technical Notes Contents. Old Contents: No documentation needed. 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: Cause: IPA permission plugin does not verify that the set of attributes specified for the new permission are relevant to the target object type that the permission allows access to. Consequence: User can create permission allowing access to attributes that will never be present in the target object's because it is not allowed in its object classes. This may rise wrong expectations about the allowed attributes in the target object. Workaround: Double-check that the chosen set of attributes for which the new permission grants access to is relevant to the chosen target object type. Result: Permission includes only attributes relevant to the target object type. Reverted patches upstream. master: 1a26406db258fe9b687ad424d55d2bf50bc74b3f 4416c185de3534ed4ed55f90f8d1b1d215f918e2 ipa-2-2: ee8ff3adf8b8214598c51d9b052f68cedf105cd1 fab98c7f0d48bb2fa48483ad47f14c1871c4c193 Using ipa-server-2.2.0-12.el6.x86_64, verified orginally reported bug behaves as technoted: # ipa permission-add ManageUser --permissions=write --type=user --attr=ipaclientversion ----------------------------- Added permission "ManageUser" ----------------------------- Permission name: ManageUser Permissions: write Attributes: ipaclientversion Type: user But - behaviour as mentioned in comment 11 has changed. Will open new bug for that Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,4 +1 @@ -Cause: IPA permission plugin does not verify that the set of attributes specified for the new permission are relevant to the target object type that the permission allows access to. +The Identity Management permission plug-in does not verify that the set of attributes specified for a new permission is relevant to the target object type that the permission allows access to. This means a user is able to create a permission which allows access to attributes that will never be present in the target object type because such attributes are not allowed in its object classes. You must ensure that the chosen set of attributes for which a new permission grants access to is relevant to the chosen target object type.-Consequence: User can create permission allowing access to attributes that will never be present in the target object's because it is not allowed in its object classes. This may rise wrong expectations about the allowed attributes in the target object. -Workaround: Double-check that the chosen set of attributes for which the new permission grants access to is relevant to the chosen target object type. -Result: Permission includes only attributes relevant to the target object type. 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 |