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 18489 invoked from network); 26 Oct 2020 13:13:10 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 26 Oct 2020 13:13:10 -0000 Received: (qmail 7569 invoked by uid 550); 26 Oct 2020 13:13:09 -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 7550 invoked from network); 26 Oct 2020 13:13:08 -0000 Date: Mon, 26 Oct 2020 09:12:55 -0400 From: Rich Felker To: Florian Weimer Cc: Jesse Hathaway , musl@lists.openwall.com, Arjun Shankar , Carlos O'Donell Message-ID: <20201026131254.GL534@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <874kmhdvqw.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Plans to remove nscd in Fedora On Mon, Oct 26, 2020 at 01:20:23PM +0100, Florian Weimer wrote: > * Jesse Hathaway: > > > On Fri, Oct 23, 2020 at 8:29 AM Carlos O'Donell 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. > > But Go and Haskell are really old by now, and nscd support hasn't landed > in those language run-times (and their de-facto default > implementations). After ten to thrity years of waiting, is it still > reasonable to expect that this might happen. > > Even for C, there is no push to make nscd a mandatory installation > requirement once the system uses services beyond the “dns” and “files” > modules. I would have expected to see a development in this direction > by now there as well. It's not just that we have turned down such > requests, they did not even happen. It's not mandatory on glibc, but it's a widely deployed existing interface on most "big" systems, and it's easy to add with a quick apt-get or whatever on others if you find you need it for integration with non-glibc binaries. If it remains easy to add, having it not installed by default is really not a big deal, but I kinda worry about bitrot/breakage from suddenly having far fewer users. > I suspect it's just that users that have large databases under /etc or > require on remote integration have little interest in static linking and > vice versa. It's not that they have interest in static linking. It's that providers of applications who want a binary that "runs anywhere" do. FWIW its presence would also let you fix the issue of lookups from (truely-, not mostly-) static-linked glibc programs not working right, just by goind to nscd first when it's present. > An added complication is that a model involving a separate daemon does > not work well for containers. Sure it does. The daemon containerizes just like everything else. Whether the host outside the container is using nscd is irrelevant to the guest inside, and vice versa. Typically inside containers you *don't* want to integrate with big shared user identities somewhere outside, but you can if you want. Rich