Bug 783502

Summary: ipa permission-add does not fail if using invalid attribute
Product: Red Hat Enterprise Linux 6 Reporter: Namita Soman <nsoman>
Component: ipaAssignee: Rob Crittenden <rcritten>
Status: CLOSED ERRATA QA Contact: IDM QE LIST <seceng-idm-qe-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2CC: 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
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 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