[Freeipa-devel] Objectclasses for target filters in default permissions
Petr Viktorin
pviktori at redhat.com
Thu Jan 9 13:05:47 UTC 2014
On 01/09/2014 02:02 PM, Martin Kosek wrote:
> 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.
OK
>> 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.
Well, I've only listed what is allowed in permissions' --type option now.
We can add others as we design read permissions for them.
> Just the pwpolicy object do now have our own objectclass, but I think we could
> work with costemplate and krbpwdpolicy objectclasses.
--
Petr³
More information about the Freeipa-devel
mailing list