Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 3 Nov 2020 10:41:05 -0500
From: Rich Felker <>
To: Florian Weimer <>
Cc: Jesse Hathaway <>,,
	Arjun Shankar <>,
	Carlos O'Donell <>
Subject: Re: Plans to remove nscd in Fedora

On Tue, Nov 03, 2020 at 10:07:23AM +0100, Florian Weimer wrote:
> * Rich Felker:
> > Thanks for filling me in on the status of this. Perhaps
> > (not part of musl, but by a
> > long-time contributor) would be a useful basis for building a
> > replacement glibc systems could use too?
> There is also unscd: <>
> It covers fewer maps, though.
> For a full solution, we would need something that can deal (correctly)
> with the shadow database.  That's currently always in-process because we
> rely on the permissions of the calling process.

Shadow was discussed when this was written, and was deemed outside the
scope for the intended goal of enabling access to centralized user
databases. As far as we could tell (at least as I remember), existing
systems aren't using shadow this way, and if passwords are being
centrally managed at all (and if they're used at all), they could just
be distributed through getpw*() only to authorized clients. Still,
shadow support could be useful for alternate local backends (like the
tcb shadow support musl has internally, or shadow-in-homedir).

The bigger omission is probably hosts and all the other obscure
databases. musl does not use nscd protocol for hosts because dns was
deemed a better existing protocol for bridging hostname lookups to
arbitrary backends, and the nscd protocol was deemed deficient for
offering additional functionality beyond what dns could offer (e.g. it
can't represent scope ids for link-local results).


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.