[SSSD] Behaviour of getgrnam/getgrgid

Simo Sorce ssorce at redhat.com
Thu Sep 16 18:16:56 UTC 2010


On Thu, 16 Sep 2010 17:50:28 +0200
Ralf Haferkamp <rhafer at suse.de> wrote:

> Hi,
> 
> On Thursday 09 September 2010 15:14:10 Ralf Haferkamp wrote:
> [..]
> > 
> > I have started working on a patch to let sssd look up the non-cached
> > users via LDAP (and save them into the cache). Find it attached.
> > Note: That patch is not really complete (e.g. it doesn't handle
> > rfc2307 groups correctly). But before putting more effort into this
> > I like to make sure that I am not trying to fix a "feature" here.
> 
> Find a newer version of my patch attached. Actually it's 3 patches
> now. Please review.
> 
> Patch1: This just adds a new flag to save_groups() to indicate that
> the group's member attribute is already populated with the members'
> sysdb DN (instead on LDAP DNs). As I need to lookup the group members
> in sysdb anyway, when processing the group, this saves some redundant
>    sysdb lookups when storing the group.

This looks like a good idea.

> Patch2: This is a somewhat improved version of my last patch. 
>    - better error handling
>    - limit the number of LDAP requests that are issued before
>      starting to process the results. This is especially needed when 
>      dealing with large groups, otherwise the server might choke on us
>      (e.g. OpenLDAP has a (configurable) limit of 100 pending
> operations per anonymous connection and 1000 per authenticated
> connection). OTOH sending multiple LDAP request at once will speed up
> things a bit compared to just sending the next request after
> processing the result of the previous.
>    - populate the "member" attribute with the correct sysdb DNs to 
>      utilize Patch1.
>    - limit the group unrolling to rfc2307bis for now. rfc2307 and IPA
>      need to be treated differently as discussed previously in this 
>      thread.

This patch makes the main function very complex, I suggest that you at
least create separate functions for each new tevent request you want to
create, that is sort of a rule for sssd. (And it makes code digestible
more often than not).

As for group unrolling I have also started working on it (ticket #625),
although I am doing that in the 1.2.x branch as we need the
functionality there too. I will try to post a patch soon so that we can
compare relative approaches and merge the effort, ok ?

> Patch3: This adds a new config option to "ldap_unroll_group_members"
> to enable/disable group unrolling

Can we use the followin patch instead ?
http://fedorapeople.org/gitweb?p=simo/public_git/sssd.git;a=commitdiff;h=fedf324be284de71e5dbf22f0135e9f681a15bde

This patch assumes the code will consider a nesting level of 0 as "no
nesting". therefore it will embed in a single option both a way to
enable disable unrolling and a limit on the level of nesting we will
allow on the client (to avoid loops or very long delay on pathological
cases).

Simo.


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



More information about the sssd-devel mailing list