On Wed, 2012-11-14 at 08:48 -0500, Stephen Gallagher wrote:
On Wed 14 Nov 2012 01:24:15 AM EST, Paul B. Henson wrote:
On Nov 13, 2012, at 9:06 PM, Simo Sorce simo@redhat.com wrote:
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.
If you have a reliance on an app using getgr lookups, you probably
shouldn't enable an option called "ignore_group_members" ;). The trade off you're making for that increased performance is that you're not going to get group members via that interface.
I just don't see a mechanism that returns a subset of members
depending on who's happened to log in recently as desirable. From a sysadmin perspective, I'd rather it reproducibly returns no members than return a potentially different subset on each call. "Hmm, the app seems to work right after bob logs in but then stops working a few hours later"...
For what it's worth, I agree with Paul here. If someone is setting 'ignore_group_members', they're already explicitly stating that they don't want to see group members come back from 'getgrnam()'. We should be guaranteed consistency here.
Ok, put down this way it tips my opinion toward the currently proposed patch.
Simo.