[SSSD] Ticket #1376 -- Add support for suppressing group members

Simo Sorce simo at redhat.com
Wed Nov 14 05:06:51 UTC 2012


On Tue, 2012-11-13 at 17:59 -0800, Paul B. Henson wrote:
> On Tue, Nov 13, 2012 at 08:08:20PM -0500, Simo Sorce wrote:
> 
> > Is this part really necessary ?
> > 
> > If you do not fetch members from LDAP then memberuid will usually be
> > empty anyway. In any case even if there is something (initgroups ?) then
> > what you have there is only members that actually have logged in and
> > that *is* information you may want to have so that applications that may
> > (naively) use a getgrnam() call in order to check membership of a
> > specific user will not fail at least for logged in users.
> 
> Without this part, getgr calls will sometimes return members, and
> sometimes not, depending on the state of the local cache and what else
> has been looked up, as well as how long the ignore_group_members option
> has been set (if you look up a group without that option set, set it and
> restart sssd, you'll get all members of the group as they're still in
> the cache).
> 
> It seems a lot more consistent to simply never return any members than
> to sporadically return some members sometimes. However, my main goal for
> the feature is to avoid the (relatively) expensive LDAP lookup, so
> functionally it doesn't really matter too much to me. You guys surely
> have a better idea of how you want the software to operate than a
> drive-by contributor ;), so I won't argue against dropping that piece if
> that's what the concensus is among primary developers.
> 
> Thanks...

Well my concern is allowing people to get the perf. benefit you need, as
you may not be the only one who needs it, w/o causing issues for those
apps that will use getgrnam() or getgrgid() to check stuff.

Maybe we can make this second part optional by changing your parameter
into a tristate, where you can go from normal, to no ldap lookups but
return what we have in cache, to never return anything even from the
cache.

I am not dead set on this, because there is value in simplicity as well
as better predictability too, so I'll let other give a thought and
comment as well.

Simo.

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




More information about the sssd-devel mailing list