[Freeipa-devel] Objectclasses for target filters in default permissions

Martin Kosek mkosek at redhat.com
Thu Jan 9 13:02:11 UTC 2014


On 01/09/2014 01:15 PM, Petr Viktorin wrote:
> Hello,
> When I'm done with [#4074], the "type" permissions will use a target filter, e.g.:
> 
>     ipa permission-add \
>         'Modify Account Expiration' \
>         --attr=krbPrincipalExpiration \
>         --type=user --perm=write
> 
> should result in this ACI at cn=users,...:
> 
>     (targetattr = "krbPrincipalExpiration")
>     (targetfilter = "(objectclass=ipauser)")
>     (version 3.0;
>         acl "permission:Modify Account Expiration";
>         allow (write) groupdn = "ldap:///cn=Modify Account
> Expiration,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com";)
> 
> The probjem is matching the "user" type with the "ipauser" objectclass.
> I've looked, but I don't think we have such "canonical objectclasses" defined
> anywhere in the code. There is object_class and possible_objectclasses for each
> object type in the plugins, but these aren't adequate: user has "posixaccount";
> some have multiple objectclasses listed (even `top` in one case). (Of course
> it's not a problem to add multiple classes to the filter, it just seems
> superfluous.)
> I'd like to add a new attribute to LDAPObject that lists the objectclass(es)
> for permission filters. This would also mean the list of allowed `type`s for
> permissions can be pulled from the plugins, rather than being hardcoded in the
> aci/permission plugin.

Sounds like a good idea.

> 
> Here's a list of proposed classes, and the existing lists for reference:
> 
> 
> user:
>     proposed for filter: ipauser
>     object_class: posixaccount
>     possible_objectclasses: meporiginentry, ipauserauthtypeclass, ipauser,
> ipatokenradiusproxyuser

Not sure about this one. ipauser is only given to the new users, after ipausers
was introduced, right?

In this case, posixaccount may be a better choice.

> 
> group:
>     proposed for filter: ipausergroup
>     object_class: ipausergroup
>     possible_objectclasses: posixGroup, mepManagedEntry, ipaExternalGroup
> 
> host:
>     proposed for filter: ipahost
>     object_class: ipaobject, nshost, ipahost, pkiuser, ipaservice
>     possible_objectclasses: (none)
> 
> service:
>     proposed for filter: ipaservice
>     object_class: krbprincipal, krbprincipalaux, krbticketpolicyaux, ipaobject,
> ipaservice, pkiuser
>     possible_objectclasses: ipakrbprincipal
> 
> hostgroup:
>     proposed for filter: ipahostgroup
>     object_class: ipaobject, ipahostgroup
>     possible_objectclasses: (none)
> 
> netgroup:
>     proposed for filter: ipanisnetgroup
>     object_class: ipaobject, ipaassociation, ipanisnetgroup
>     possible_objectclasses: (none)
> 
> dnsrecord:
>     proposed for filter: idnsrecord
>     object_class: top, idnsrecord
>     possible_objectclasses: (none)

Looks good to me. You also missed some other non-account object like SUDO or
HBAC, but it should be easy there as they usually have a ipa* canonical base
objectclass, i.e. ipahbacrule, ipahbacservice,
ipahbacservicegroup, ipaselinuxusermap, ipasudocmd, ipasudocmdgrp, ipasudorule,
ipaNTTrustedDomain.

Just the pwpolicy object do now have our own objectclass, but I think we could
work with costemplate and krbpwdpolicy objectclasses.

Martin




More information about the Freeipa-devel mailing list