From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 318501F670 for ; Tue, 1 Mar 2022 09:11:38 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0942E385842E for ; Tue, 1 Mar 2022 09:11:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0942E385842E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1646125897; bh=YcpoTIPaRvwm5ApXqd4HgP52rvMwQqN5AKxhPJKcVSg=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=vaAuwbHZ3S7SioAhReUh/OukOeyybXCLr0b682ez4ClK+DJ4/NZpQJ7Zwv3CUYwPS yErRUE7hJuR32VDtiwCZdZ5pV9Xth5M7cf1LqAqWuDLBUzAELK3C84qZYW8y2wU0s5 +YW43pDSR+yEPVUrFUE/L5gqK+NGsmBJR+I63yHM= Received: from hera.aquilenet.fr (hera.aquilenet.fr [185.233.100.1]) by sourceware.org (Postfix) with ESMTPS id DAAF5385840C for ; Tue, 1 Mar 2022 09:10:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DAAF5385840C Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 1408C29C; Tue, 1 Mar 2022 10:10:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86g1UynjS7NL; Tue, 1 Mar 2022 10:10:48 +0100 (CET) Received: from ribbon (unknown [IPv6:2001:660:6102:320:e120:2c8f:8909:cdfe]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 3BA99FE; Tue, 1 Mar 2022 10:10:47 +0100 (CET) To: DJ Delorie Subject: Re: On the removal of nscd from Fedora, and the future of nscd. References: X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 11 =?utf-8?Q?Vent=C3=B4se?= an 230 de la =?utf-8?Q?R?= =?utf-8?Q?=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Tue, 01 Mar 2022 10:10:46 +0100 In-Reply-To: (DJ Delorie's message of "Mon, 28 Feb 2022 18:02:57 -0500") Message-ID: <87czj682cp.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / X-Rspamd-Server: hera X-Rspamd-Queue-Id: 1408C29C X-Spamd-Result: default: False [-0.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_TLS_ALL(0.00)[] X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: =?utf-8?q?Ludovic_Court=C3=A8s_via_Libc-alpha?= Reply-To: =?utf-8?Q?Ludovic_Court=C3=A8s?= Cc: ashankar@redhat.com, libc-alpha@sourceware.org, fweimer@redhat.com Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" Hello, Thank you Carlos for the introduction! DJ Delorie skribis: > "Carlos O'Donell" writes: >> Ludovic reached out to me regarding the removal because Guix uses nscd >> for the interesting use case of supporting multiple system libcs: >> https://guix.gnu.org/manual/devel/en/html_node/Application-Setup.html#Na= me-Service-Switch-1 > > I think this is a weak argument. If Guix can dlopen the host system's > objects, you risk incompatibilities anyway. And we don't have a rule > that says that nsswitch modules have to be built against the exact > version of glibc you're running against, although if the module is too > new there may be problems. But Guix would have this problem anyway if > both sets of objects are available. If Guix wants to run its own glibc, > it needs to be isolated better - meaning, its own nscd, its own path to > nss modules, etc. Almost like a container or flatpack. It may not even > be able to parse /etc/nsswitch.conf if the host system is newer. To be clear, Guix applications have been used on top of other distros just fine. This nscd requirement is one of the few must-haves to ensure, as Joseph writes, that processes (in particular those linked against Guix=E2=80=99s libc) do not end up dlopening arbitrary, possibly incompatible libraries. (The problem applies to other deployment tools that are not limited to a single system libc such as Nix.) I like the idea of keeping a trimmed-down nscd as Carlos wrote. Calling out to =E2=80=98getent=E2=80=99 would also work, but it potentially means h= aving one =E2=80=98getent=E2=80=99 process per application, if I understand Florian= =E2=80=99s proposal correctly. Thanks, Ludo=E2=80=99.