[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANSNSoXvHSN6fBo6oAdZzC7OFrrekAxSiFCY9XZ-tp5wTCTCJA@mail.gmail.com>
Date: Fri, 23 Oct 2020 09:14:01 -0500
From: Jesse Hathaway <jesse@...ki-mvuki.org>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>, Arjun Shankar <arjun@...hat.com>,
Florian Weimer <fweimer@...hat.com>
Subject: Re: Plans to remove nscd in Fedora
On Fri, Oct 23, 2020 at 8:29 AM Carlos O'Donell <carlos@...hat.com> wrote:
> My opinion is that we want something much thinner than nscd to provide
> NSS for statically linked applications, and that such an interface
> should not provide caching. If we really wanted we could keep the nscd
> socket interface but implement an NSS daemon for this e.g. nssd that would
> just run all the time and could be depended upon by static applications.
> It would have to be well audited and very simple.
>
> The caching that nscd does has many legacy problems that are better solved
> and maintained by other daemons that implement a split NSS module approach
> (as Florian notes).
Given the increasing prevalence of statically deployed programs from languages
such as C, Go, Rust, and even Haskell. I would love to see continued
distribution support for querying NSS from these programs. An nscd variant
without caching seems like a good approach, but I think it would be unfortunate
to remove nscd from distributions before an alternative approach was available.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
