Date: Tue, 3 Nov 2020 10:41:05 -0500 From: Rich Felker <dalias@...c.org> To: Florian Weimer <fweimer@...hat.com> Cc: Jesse Hathaway <jesse@...ki-mvuki.org>, musl@...ts.openwall.com, Arjun Shankar <arjun@...hat.com>, Carlos O'Donell <carlos@...hat.com> 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 > > https://github.com/pikhq/musl-nscd (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: <https://busybox.net/~vda/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). Rich
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.