On 01/09/2014 02:02 PM, Martin Kosek wrote:
On 01/09/2014 01:15 PM, Petr Viktorin wrote:
When I'm done with [#4074], the "type" permissions will use a target filter,
ipa permission-add \
'Modify Account Expiration' \
should result in this ACI at cn=users,...:
(targetattr = "krbPrincipalExpiration")
(targetfilter = "(objectclass=ipauser)")
acl "permission:Modify Account Expiration";
allow (write) groupdn = "ldap:///cn=Modify Account
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
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
Sounds like a good idea.
Here's a list of proposed classes, and the existing lists for reference:
proposed for filter: ipauser
possible_objectclasses: meporiginentry, ipauserauthtypeclass, ipauser,
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.
proposed for filter: ipausergroup
possible_objectclasses: posixGroup, mepManagedEntry, ipaExternalGroup
proposed for filter: ipahost
object_class: ipaobject, nshost, ipahost, pkiuser, ipaservice
proposed for filter: ipaservice
object_class: krbprincipal, krbprincipalaux, krbticketpolicyaux, ipaobject,
proposed for filter: ipahostgroup
object_class: ipaobject, ipahostgroup
proposed for filter: ipanisnetgroup
object_class: ipaobject, ipaassociation, ipanisnetgroup
proposed for filter: idnsrecord
object_class: top, idnsrecord
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,
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.
Freeipa-devel mailing list