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 _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
