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