[Freeipa-devel] Ticket #2293 - permission attribute check

[Rob Crittenden]

Ondrej Hamada wrote:
> On 04/27/2012 02:36 PM, Martin Kosek wrote:
>> I revisited ticket #2293 after it failed QE check. After some
>> considerations, I think we should revert this type of check for
>> permissions. Here is my reasoning:
>>
>> 1) This check fails when the target type does not have all its possible
>> objectclasses defined in the LDAPObject, like when users or hosts miss
>> kerberos or samba auxiliary classes as they are just classes that the
>> object may potentially have:
>>
>> # ipa permission-mod "Change a user password"
>> --attrs=userpassword,krbprincipalkey,sambalmpassword,passwordhistory
>> ipa: ERROR: attribute(s) "sambalmpassword,passwordhistory" not allowed
>>
>> To fix this point, we would need to add all possible object classes to
>> our user, host, ... objectclasses.
>>
>>
>> 2) It severely limits permission flexibility for custom user
>> objectclasses. They would need to extend our plugins to make them work.
>> Observe this inconsistency:
>>
>> Setting custom OC+attribute works (replace "sudocmd" with some
>> meaningful object class"):
>>
>> # ipa user-mod fbar --addattr=objectclass=ipasudocmd
>> --setattr=sudocmd=fbar
>> --------------------
>> Modified user "fbar"
>> --------------------
>> User login: fbar
>> First name: Foo
>> Last name: Bar
>> Home directory: /home/fbar
>> Login shell: /bin/sh
>> UID: 61400016
>> GID: 61400016
>> Account disabled: False
>> Password: True
>> Member of groups: ipausers
>> Kerberos keys available: True
>>
>> # ipa user-show --all fbar
>> dn: uid=fbar,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
>> User login: fbar
>> First name: Foo
>> Last name: Bar
>> ...
>> mepmanagedentry:
>> cn=fbar,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
>> objectclass: top, person, organizationalperson, inetorgperson,
>> inetuser, posixaccount,
>> krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser,
>> ipaSshGroupOfPubKeys,
>> mepOriginEntry, ipasudocmd
>> sudocmd: fbar
>>
>>
>> But adding a custom permission to control this attribute fails:
>> # ipa permission-add "Can manage user sudocmd" --type=user
>> --permissions=write --attrs=sudocmd
>> ipa: ERROR: attribute(s) "sudocmd" not allowed
>>
>>
>> Bottom line is that I would remove this check at all and just check that
>> the attribute is right - as we already do for permission without
>> "--type" specified:
>>
>> # ipa permission-add "Can write barbar"
>> --filter="(objectclass=posixuser)" --permissions=write --attrs=barbar
>> ipa: ERROR: targetattr "barbar" does not exist in schema. Please add
>> attributeTypes "barbar" to schema if necessary. ACL Syntax
>> Error(-5):(targetattr = \22barbar\22)(targetfilter =
>> \22(objectclass=posixuser)\22)(version 3.0;acl \22permission:foo
>> \22;allow (write) groupdn =
>> \22ldap:///cn=foo,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com\22;):
>> Invalid syntax.
>>
>> Martin
>>
> What about simply let the command succeed and print out a warning like:
> 'Attribute "passwordhistory" is not a default one for specified object
> type. The permission might not be properly evaluated.'
>

For IPA 2.2 we are going to revert the check. For 3.0 we will re-add the 
check and make it non-fatal and instead return a warning to the user 
that some attributes may not apply to this object.

rob