[SSSD] Behaviour of getgrnam/getgrgid

Ralf Haferkamp rhafer at suse.de
Fri Sep 10 10:06:25 UTC 2010


On Thursday 09 September 2010 18:33:26 Simo Sorce wrote:
> On Thu, 9 Sep 2010 08:57:37 -0700
> 
> Jeff Schroeder <jeffschroeder at computer.org> wrote:
[..]
> > Having enumerate = False but still enumerate the members of each
> > group (when the group is looked up) would be nice. Some users got
> > really confused with the output of getent group showed them in the
> > right groups, but not all of the members.
> > 
> > Remember that while optimizing for hte 50k member group is
> > important, it is likely not the most common usage scenario.
> 
> Ok, I was also wondering we can use a slightly different set of
> heuristics depending on what kind of schema is used.
> 
> So we have the following scenarios:
> 
> 1) If we use rfc2307 classic with memberUid attributes, we can just
> create the fake/expired users and be done with it.
Agreed.
 
> 2) If we use rfc2307bis w/o nested groups we can count the number of
> members on the group entry and switch to a full user enumeration if
> the number of members is greater than a defined (potentially user
> defined) threshold. Assuming a threshold value of 100, if we have 10
> members we just do 10 lookups, while, if we have > 100 member we do a
> full enumeration (it's a single ldap search, and if modifyTimestamp
> is used also highly optimized after the first search) so we are sure
> all users are there with the right name.
I think that's an optimization that could be worth exploring later. In a 
first iteration I'd just go for implementing the complete group lookup by 
looking up every single user regardless of how large the group is. (plus 
the possiblity to completely disable member unrolling through the 
configuration)
 
> 3) If we use rfc2307bis with nested groups we do the same as in 2, but
> we add an internal user lookup against the cache we just populated to
> determine if some members are groups that need further lookups in
> order to complete the group unrolling operation.
Why do an extra cache lookup? You could issue the addtional LDAP lookups 
right when you receive the entries of the group members. Provided the 
correct LDAP attributes where requested (i.e. user attributes + groups 
attributes).

> 4) If we use IPA (rfc2307bis + nested groups + unrolled members in
> memberOf attribute), we can do a single search with memberOf=groupDN,
> as IPa's memberOf fully resolves nested groups. This would return all
> and only the users members of the group.
> So if the group has 101 members in a directory of 50k users we do not
> do a full 50k users enumeration just because we have a group that is 1
> above the threshold. 
> 
> Do I miss any scenario ?
> 
> Simo.

regards,
	Ralf



More information about the sssd-devel mailing list