[SSSD] [PATCH] fix nested groups

Simo Sorce ssorce at redhat.com
Mon Nov 30 12:44:10 UTC 2009


On Mon, 2009-11-30 at 11:47 +0100, Sumit Bose wrote:
> On Fri, Nov 27, 2009 at 07:13:55PM -0500, Simo Sorce wrote:
> > When I did the enumgrent optimization patch I totally forgot about
> > nested groups for some reason.
> > Of course I broke them. The gain in performance although was just way
> > too substantial to just revert to the previous way of resolving nested
> > groups again and again at every search.
> > 
> > These 2 patches instead store unrolled groups by adding a new
> > operational attribute: memberuid
> > This attribute contains just the user name of any user directly or
> > indirectly (through a nested group) members of a group.
> > This way computation is done once at modify time and never again.
> > 
> > Fixes bug #291
> > 
> > Simo.
> > 
> 
> 0001 does not compile:
> 
> ldb_modules/memberof.c: In function 'memberof_del':
> ldb_modules/memberof.c:1152: error: 'el' undeclared (first use in this
> function)
> ldb_modules/memberof.c:1152: error: (Each undeclared identifier is
> reported only once
> ldb_modules/memberof.c:1152: error: for each function it appears in.)

I will check, builds and tests fine here.

> Do I miss another patch which fixes this?
> 
> Why do you save 'only' the name attribute in memberuid and not the DN?

Because these are all users, the DN is reconstructed quite easily.
It's part of the optimization, having to dissect a DN at every query is
just a lot of work for nothing.

> It is ok for the nested groups use case, but I think from a general pov
> it would make sense to store the DN, e.g. if we need to store generic,
> i.e. non-posix, IPA groups where objects might not have a name
> attribute.

This is only for NSS, if we need member/memberof, unless the tartget
entry is of type objectclass=user no memberuids are generated in the
groups.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list