On Wed, Sep 29, 2010 at 3:40 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
On 09/28/2010 07:02 PM, Jeff Schroeder wrote
> Not for the sake of being argumentative, but for the sake of
> completeness, why do you want to change the semantics of what an admin
> would expect? Especially when most people using sssd are former
> pam_ldap users and expect things like netgroups to work a certain way?
> While not disagreeing, I'm just curious as to the reasoning.
Well, as I was trying to explain in the original email, there are
several advantages to doing this differently.
1) Much higher performance. If we perform the nested lookups inside of
SSSD, we can potentially perform multiple parallel lookups and save us
the time of repeated round-trips from LDAP.*
2) We can provide an option for nesting limits. Right now, glibc will
always follow nested netgroups down as far as it can go. In a
pathological case, this could be thousands of nestings deep. That can be
These are both excellent reasons to use sssd.
3) We guarantee that the central LDAP store is authoritative for
netgroups. Doing things this way ensures that if a netgroup arrangement
is set up on the server, no local change will interject unexpected
values into the mix, intentionally or otherwise.
I'm not sold on this idea whatsoever. If you have access to change
nss, you have access to disable sssd / futz the ldap configuration.
While this is a noble goal, configuration management is for ensuring
valid configurations. As I so eloquently say, "You can't protect a
system from a stupid admin."
* It occurred to me while writing this email that even if we did go
the traditional behavior, we could still probably pre-cache the nested
groups so that when glibc requests them we can serve them from cache. Of
course, this can also be a waste of processing time if it turns out that
one of the nested members (potentially one that has other, further
nested members) is in fact being overridden on the client.
Just trying to keep you gents on your toes. Keep up the great work and
thanks for answering my questions.
Don't drink and derive, alcohol and analysis don't mix.