From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27351 invoked from network); 3 Nov 2020 15:41:21 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Nov 2020 15:41:21 -0000 Received: (qmail 25713 invoked by uid 550); 3 Nov 2020 15:41:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 25692 invoked from network); 3 Nov 2020 15:41:17 -0000 Date: Tue, 3 Nov 2020 10:41:05 -0500 From: Rich Felker To: Florian Weimer Cc: Jesse Hathaway , musl@lists.openwall.com, Arjun Shankar , Carlos O'Donell Message-ID: <20201103154104.GV534@brightrain.aerifal.cx> References: <1924902939.18027073.1603105167534.JavaMail.zimbra@redhat.com> <805098991.18032044.1603106011330.JavaMail.zimbra@redhat.com> <20201020010855.GE17637@brightrain.aerifal.cx> <874kmhdvqw.fsf@oldenburg2.str.redhat.com> <20201026131254.GL534@brightrain.aerifal.cx> <87zh3zg8yw.fsf@oldenburg2.str.redhat.com> <20201102145017.GS534@brightrain.aerifal.cx> <87blgeerlg.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87blgeerlg.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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: > 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