[SSSD] [PATCHES] Alternative objectClass for group maps

Sumit Bose sbose at redhat.com
Wed Sep 10 14:00:29 UTC 2014


On Wed, Sep 10, 2014 at 03:06:07PM +0200, Jakub Hrozek wrote:
> On Wed, Sep 10, 2014 at 02:55:34PM +0200, Sumit Bose wrote:
> > On Wed, Sep 10, 2014 at 02:33:00PM +0200, Jakub Hrozek wrote:
> > > On Wed, Sep 10, 2014 at 02:22:15PM +0200, Sumit Bose wrote:
> > > > On Wed, Sep 10, 2014 at 01:23:15PM +0200, Michal Židek wrote:
> > > > > Hi,
> > > > > 
> > > > > this patch should solve regression on IPA server
> > > > > triggered by the patches for this ticket:
> > > > > https://fedorahosted.org/sssd/ticket/2343
> > > > > 
> > > > > Patches for #2343 solved the IPA side of the
> > > > > problem by searching for objectclass groupOfNames
> > > > > instead of posixGroup (which was not available in
> > > > > non-posix groups). But (as we discovered now) not
> > > > > all groups in IPA are members of the objectClass
> > > > > groupOfNames (the private groups created
> > > > > automatically for users are not, so as a result
> > > > > we were not able to query them). So there is
> > > > > no common objectclass for all groups in IPA that
> > > > > would be suitable for group query filters.
> > > > > 
> > > > > So these 2 patches add the possibility to query
> > > > > groups using primary and alternative objectClass
> > > > > (ORed in the filter).
> > > > > 
> > > > > I tested the patches, but I would feel safer if
> > > > > someone pushed them to Beaker and run QE tests
> > > > > on it before pushing (I thing Jakub volunteered
> > > > > for this task off-list :) ).
> > > 
> > > No, I volunteered for writing a unit test for these changes.
> > > 
> > > > > 
> > > > > Thank you,
> > > > > Michal
> > > > 
> > > > While I agree with the general approach I think the default for the
> > > > alternative objectclass should be NULL at it should only be added to the
> > > > search filter if defined. Maybe a function returning either
> > > > "(objectClass=group_oc)" or
> > > > "(|(objectClass=group_oc)(objectClass=alt_group_oc))" might help here.
> > > 
> > > Yes please, we need a separate function that returns the objectclass
> > > filter.
> > > 
> > > > 
> > > > I guess you did not include changes to the man page and the config API
> > > > on purpose to make it hard to change or unset the values. But
> > > > nevertheless it is a config option and should be handled as such.
> > > 
> > > Another change I would like to see is make the alt_objectclass a list
> > > instead of a single string as you suggested on IRC.
> > 
> > maybe, but see my comment below.
> > 
> > > 
> > > > 
> > > > I understand that we need a fix for the issue fast because it is in
> > > > already released. Hence I would agree if trac tickets are created for
> > > > the issues above for the next release.
> > > 
> > > Fine by me.
> > > 
> > > Another question -- do we want to extend the other maps, too (OK by me
> > > to do this in master only)
> > 
> > I think options which allow to override the search filters which are
> > currently discussed on sssd-users are the more general solution here.
> > With this the user is free to add any number of objectclasses.
> > 
> > bye,
> > Sumit
> 
> I agree they are more flexible, but we need to extract the objectclass
> somehow in order to match the object with an appropriate maps. I'm not
> sure if libldap offers some functionality to parse a filter on the
> client side, do you think we could write a filter parser ourselves?

I think we still have to use the ldap_*_objectclass options to do this
mapping. Even if we can parse the filter string it might be difficult to
find out which objectclass is the characteristic one for the object.

If it turns out that there are use cases similar to the IPA groups for
other objects I think it would make more sense to allow a comma
separated list for the ldap_*_objectclass options. I'm not sure if this
an alternative for adding the new ldap_group_objectclass_alt option if
the search filter is generated by a separated function?

bye,
Sumit

> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list