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

[Ondrej Hamada]

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.'

-- 
Regards,

Ondrej Hamada
FreeIPA team
jabber: ohama at jabbim.cz
IRC: ohamada