[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