RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 783502 - ipa permission-add does not fail if using invalid attribute
Summary: ipa permission-add does not fail if using invalid attribute
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ipa
Version: 6.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Rob Crittenden
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks: 817401
TreeView+ depends on / blocked
 
Reported: 2012-01-20 16:18 UTC by Namita Soman
Modified: 2013-08-19 14:04 UTC (History)
4 users (show)

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.
Clone Of:
: 817401 (view as bug list)
Environment:
Last Closed: 2012-06-20 13:31:16 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0819 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2012-06-19 20:34:17 UTC

Description Namita Soman 2012-01-20 16:18:56 UTC 
Description of problem:
When adding a permission, where attribute is not an allowed attr for the type being used, there is no error. And permission is added successfully

# ipa permission-add ManageUser --permissions=write --type=user --attr=ipaclientversion

-----------------------------

Added permission "ManageUser"

-----------------------------

  Permission name: ManageUser

  Permissions: write

  Attributes: ipaclientversion

  Type: user




Doc says:
The attributes (--attrs) must exist and be allowed attributes for the given object type, or the permission operation fails with schema syntax errors. 

Version-Release number of selected component (if applicable):
freeipa-server-2.1.4-4.fc16.x86_64

How reproducible:
always

Steps to Reproduce:
1. add a permission as indicated above

  
Actual results:
permission is added successfully

Expected results:
the command to fail with error - ipa: ERROR: attribute "ipaClientVersion" not allowed

Additional info:
Comment 2 Rob Crittenden 2012-01-20 19:48:58 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.
Comment 3 Dmitri Pal 2012-01-20 23:18:48 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/2293
Comment 4 Rob Crittenden 2012-02-29 16:32:34 UTC 
fixed upstream.

Attributes are only checked with type is provided.

master: 1356988b7a40a60af39807db143860efb4a2f435

ipa-2-2: a331f351665d32b82cab4d6c53ae9496f38ebd9e
Comment 6 Namita Soman 2012-03-20 13:03:52 UTC 
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
Comment 7 Martin Kosek 2012-03-22 16:15:24 UTC 
Fixed upstream:
master: https://fedorahosted.org/freeipa/changeset/a58cbb985ec007c0ef83010b32408efb2f4784d2
ipa-2-2: https://fedorahosted.org/freeipa/changeset/f0006402b85683009825bb80895852ca5dc94fa6
Comment 9 Martin Kosek 2012-04-20 12:08:23 UTC 
    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.
Comment 10 Namita Soman 2012-04-26 12:03:54 UTC 
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
Comment 11 Namita Soman 2012-04-26 17:32:50 UTC 
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
Comment 13 Dmitri Pal 2012-04-29 19:52:11 UTC 
Deleted Technical Notes Contents.

Old Contents:
No documentation needed.
Comment 14 Martin Kosek 2012-04-30 12:54:58 UTC 
    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.
Comment 15 Rob Crittenden 2012-04-30 17:03:11 UTC 
Reverted patches upstream.

master:
1a26406db258fe9b687ad424d55d2bf50bc74b3f
4416c185de3534ed4ed55f90f8d1b1d215f918e2

ipa-2-2:
ee8ff3adf8b8214598c51d9b052f68cedf105cd1
fab98c7f0d48bb2fa48483ad47f14c1871c4c193
Comment 17 Namita Soman 2012-05-01 18:27:24 UTC 
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
Comment 18 Martin Prpič 2012-05-03 13:44:55 UTC 
    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.
Comment 21 errata-xmlrpc 2012-06-20 13:31:16 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.