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

[Dmitri Pal]

On 04/27/2012 11:52 AM, 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.'
>
Makes sense.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/