Bug#365048: libc6 does not respect STATUS and ACTION options in nsswitch.conf
> On Thu, Apr 27, 2006 at 10:40:32AM -0400, Jesse W. Hathaway wrote:
>
> [...]
> > struct passwd *pw = getpwnam(user);
> > if (pw == NULL)
> > return 0;
> >
> > if (getgrouplist(user, pw->pw_gid, NULL, &ng) < 0) {
> > groups = (gid_t *) malloc(ng * sizeof (gid_t));
> > getgrouplist(user, pw->pw_gid, groups, &ng);
> > }
> [...]
>
> > doing an strace on the above program when searching for a user in
> > /etc/passwd shows ldap being searched, with or without [SUCCESS=return]
> > in nsswitch.conf.
>
> The above is not a good example. Do LDAP lookups happen with a single
> getpwnam() call _only_? If yes, then it is a bug, otherwise it's not.
>
> getgrouplist() and initgroups() will _always_ enumerate all NSS group
> data sources regardless of action statements. It may be unfortunate
> sometimes due to the generated load, but this is how their semantics are
> defined. The only solution is not to use LDAP for the group database at
> all.
If this is the case then why does the man page for nsswitch.conf give
the option of specifying [SUCCESS=return] for the group database, when
this has no effect on the above functions? I think it should be noted
in nsswitch.conf's man page that the entire group list is alwasy
searched.
Why it it defined that getgrouplist() and initgroups() _always_
enumerate all NSS goups? This can cause problems for system daemons. For
instance apache2 does an initgroups every time it spawns a thread, which
results in my ldap servers being pounded when I have high load on my
webservers. Nscd is a possible solution to the problem, but the version
in stable does not cache initgroup requests, and the version in unstable
invalidates them prematurely. Having the ability to not search other
databases for local name service lookups seems like a valuable function.
> > Changing nsswitch to [UNAVAIL=return] disables ldap
> > lookups for all requests even if the user is not in /etc/passwd.
>
> Note that the UNAVAIL status refers only to the generic availability of
> the service, it has nothing to do with the user being defined or not.
>
> That said, "files [UNAVAIL=return] ldap" should not disable ldap (quite
> the contrary, it should have basically no effect unless you delete
> /etc/passwd etc.), so this may need further investigation.
>
> Gabor
Reply to: