This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Fwd: SELinux support in Libc
- From: Nix <nix at esperi dot org dot uk>
- To: Petr Baudis <pasky at suse dot cz>
- Cc: Shaz <shazalive at gmail dot com>, libc-help at sourceware dot org
- Date: Thu, 10 Jun 2010 21:27:51 +0100
- Subject: Re: Fwd: SELinux support in Libc
- References: <AANLkTinESptHxDYCPSiRJca5_-fK4DsiDwd_KQzQN6gX@mail.gmail.com><AANLkTineZEFnVtv-2XzU5LVUFpwAMWAraODhzh82kXlt@mail.gmail.com><AANLkTiknYkF6FzlZATVKYqRALcC-z7igCAnoecmyjsoA@mail.gmail.com><AANLkTimiyYf4zY-M0VIB0iEhjjn_wHlmQHl7PSsUZCel@mail.gmail.com><20100527080001.GD16800@machine.or.cz>
On 27 May 2010, Petr Baudis told this:
> On Thu, May 27, 2010 at 12:40:24PM +0500, Shaz wrote:
>> http://cblfs.cross-lfs.org/index.php/NSS_Caching mentions some
>> concepts but what can be a possible usecase to understand what this
>> object manager really achieves.
>
> The wiki page you linked seems to be pretty clear on everything (up to
> minor omissions) - the main usecase is to cache results returned by
> nss_nis, nss_ldap and such.
It's also damn useful if you've used something like the iana-etc project
to soup up /etc/services to include the full list of IANA-registered
services. A full services file is about 20000 lines long, and without
nscd every failing getservby*() call will do a full linear search of
that monster, which is *slow*. With nscd in place, this is reduced to a
binary search of a shared memory ragion: nearly instantaneous.
(of course only a madman would actually *want* a 20000 line long
/etc/services file.)