This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Security impact of nscd and NSS module bugs (particularly NIS)
- From: Thorsten Glaser <tg at debian dot org>
- To: libc-alpha at sourceware dot org
- Date: Fri, 4 Jul 2014 14:00:44 +0000
- Subject: Re: Security impact of nscd and NSS module bugs (particularly NIS)
- Authentication-results: sourceware.org; auth=none
- References: <53B54CEE dot 6040505 at redhat dot com> <20140703160829 dot GW20796 at spoyarek dot pnq dot redhat dot com> <20140703193030 dot 93B502C398D at topped-with-meat dot com> <53B670B1 dot 4090103 at redhat dot com>
Florian Weimer dixit:
> But your comment suggest to me that an nscd crash would generally be fairly
> limited in impact and not as annoying as, say, a hanging syslog process (which
> tends to take down the entire system eventually).
With my FusionForge developer hat on: nscd crashing may mean an
effective DoS. In a FusionForge setup, such as Alioth, nss_pgsql
is used, and users regularily have dozens or even hundreds of
groups, and nscd caching needs to be used for this to work.
For what itâs worth: at work, we have completely fixed all NSSâ
related stability issues in FusionForge setups by switching from
nscd (glibc) to unscd, which (AIUI) forks for each new request,
thereby eliminating propagating NSS module failures, leaks, etc.
Sure, not quite as efficient (and unscd does not cache all that
much), but a lot more stable.
bye,
//mirabilos
--
tarent solutions GmbH
RochusstraÃe 2-4, D-53123 Bonn â http://www.tarent.de/
Tel: +49 228 54881-393 â Fax: +49 228 54881-235
HRB 5168 (AG Bonn) â USt-ID (VAT): DE122264941
GeschÃftsfÃhrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg