Again, not the expert here and there's likely some wrongness in what I'm
saying, but...
I think the problem is the legacy (and still very much used) functions for
gathering group information work on the basis that a big sweep of the groups
file gathering all the information is much more sensible than lots of targeted
pokes for just what you need. So you have things like this, directly quoting
from the man pages:
The initgroups() function initializes the group access list by reading the
group database /etc/group and using all groups of which user is a member.
The getgrouplist() function scans the group database (see
group(5)) to obtain the list of groups that user belongs to. Up
to *ngroups of these groups are returned in the array groups.
struct group {
char *gr_name; /* group name */
char *gr_passwd; /* group password */
gid_t gr_gid; /* group ID */
char **gr_mem; /* NULL-terminated array of pointers
to names of group members */
};
So you use initgroups to find out about all the groups a user is a member of,
and in doing that you find out about all those groups, which means you need to
populate the group members of all those groups. Bleurgh! This is what leads
to the performance fun.
Say I'm restricting access to a service on the basis of group membership. I
can either ask "Which groups is this user a member of?", then check that the
group I want is there, or I can ask "Who is a member of this group?". The
former means full group enumeration of every group a user is a member of,
whereas the latter involves just a single group, but it's not all positive.
Using the ignore_group_members option in SSSD works around this and makes
things much faster, but there is a downside. If I go the latter route, and
we've used ignore_group_members, then when I query a group, it tells me that
nobody is a member of it.
So "What groups is Sally a member of? People". "Who is a member of People?
Nobody". That then can cause you some grief with ignore_group_members. In the
past I know newgrp would fail to work properly with this configuration.
But to be honest, these niggles are in my experience few and far between. With
a large LDAP setup, ignore_group_members is an essential performance boost.
John
--
John Hodrien (he/him)
Principal Teaching and Research Support Specialist, School of Computer Science
2.22 Bragg Building, University of Leeds
________________________________
From: Christopher Paul via sssd-users <[email protected]>
Sent: 23 July 2025 00:52
To: [email protected] <[email protected]>
Cc: Christopher Paul <[email protected]>
Subject: [SSSD-users]Re: SSSD with rfc2307bis causes thousands of concurrent
LDAP queries, triggering OpenLDAP flow control
CAUTION: External Message. Use caution opening links and attachments.
On 7/22/25 16:48, Christopher Paul via sssd-users wrote:
On 7/22/25 14:53, John Hodrien wrote:
[...]
That's my understanding anyway, but I'm not an expert.
You're probably right, but it would be nice if SSSD could retrieve groups for a
user but not look up all the members attribute values for all the other members
of each group to which one user belongs.
I notice that with "ignore_group_members = true", that the "groups <uid>"
command still works.
Oh blast it. Actually with "ignore_group_members = true", "id <uid>" also
works, and it does not look up all the members attribute values for all the
other members of each group to which one user belongs. So this feature does
exist and it's called "ignore_group_members = true".
But I guess it would be nice if "getent group <group name>" worked to list all
members without looking up their user values. I see no reason why a group
lookup should cause all members' attribute values to be looked up.
Chris
--
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
