Security impact of nscd and NSS module bugs (particularly NIS)
Thorsten Glaser
tg@debian.org
Fri Jul 4 14:01:00 GMT 2014
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
More information about the Libc-alpha
mailing list