From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 16F783858D20 for ; Mon, 28 Feb 2022 20:55:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 16F783858D20 Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-231-zwjqoMDXMem9Y3-31jx-PA-1; Mon, 28 Feb 2022 15:55:20 -0500 X-MC-Unique: zwjqoMDXMem9Y3-31jx-PA-1 Received: by mail-qv1-f70.google.com with SMTP id fh12-20020a0562141a0c00b00432f7fe8804so6028476qvb.4 for ; Mon, 28 Feb 2022 12:55:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:organization :content-transfer-encoding; bh=/DaW8tB5tZNr8Az7y+k1TbVq0EN0iA7//S1wVKIFA0E=; b=0BfWuPMNTyyBKvxz+91DvpSD9SEdZnNgnVYfb2kuWMuZE4p8RfdUTyl0nqJW5K1qfb uQU5ReKTyun+fdWBkFOByqI+eweyULhZ2P1xln2rvwiBmRsnjTgS7fYaCmvwHpfLV/rD Aje9HybQAaL8VdS37jAB80upGGnl42r67pfErN2x/8FUPnbnPSlJV4HSjcRaoN+q9D3o tP5ibCC6slI/tw5BsgkQFomsjsEhCiB7bpRmgzBgH1jSLPO5nCOgizeCTgcGL68Te5jO jVkHcA74ENCWFBH7JAMujFwgWbRS5E5QEa9ygojYx44m9wBcPOt4FO14CRjS8fh/ObJ5 Tkhw== X-Gm-Message-State: AOAM533gsvAs47o3qEGlgpEIJS0FGjGgUWVtQPFAhFM/yBZn68/JkF5h HeHoXMTArhQJS8VcBDOzSb1UsGUfE6dNzbSpn6MzmjTJKtwuIeD7ssV4gnSlszOPBdKeOiNtmtP dSgQRxUs8yIF6SHgcyM4f X-Received: by 2002:ac8:7fcc:0:b0:2de:6f5:3f5c with SMTP id b12-20020ac87fcc000000b002de06f53f5cmr18096231qtk.214.1646081719264; Mon, 28 Feb 2022 12:55:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJzQiI3jFtO8oCs6OKU4m+4NZw3aq/P+Cnr6gRKdbbxVYWlsAY/vCcRqu6KS7RoUlYC/8f01ow== X-Received: by 2002:ac8:7fcc:0:b0:2de:6f5:3f5c with SMTP id b12-20020ac87fcc000000b002de06f53f5cmr18096216qtk.214.1646081718921; Mon, 28 Feb 2022 12:55:18 -0800 (PST) Received: from [192.168.0.241] (135-23-175-80.cpe.pppoe.ca. [135.23.175.80]) by smtp.gmail.com with ESMTPSA id l19-20020a05622a051300b002dff3437923sm6049737qtx.11.2022.02.28.12.55.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Feb 2022 12:55:18 -0800 (PST) Message-ID: Date: Mon, 28 Feb 2022 15:55:17 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= , Arjun Shankar , Florian Weimer , Adhemerval Zanella , libc-alpha , DJ Delorie From: Carlos O'Donell Subject: On the removal of nscd from Fedora, and the future of nscd. Organization: Red Hat X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_MANYTO, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 28 Feb 2022 20:55:26 -0000 In Fedora 36 we officially removed nscd from the distribution with this system-wide change request: https://fedoraproject.org/wiki/Changes/RemoveNSCD I say "we" but it was the entire Fedora glibc team, which includes various developers also on this list like Arjun, Florin, and DJ. We took this action because over time glibc should focus on the important parts of being a core runtime. We felt sssd and systemd had grown to the point where they were well supported and and supporting nscd in Fedora was no longer required. 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#Name-Service-Switch-1 The idea is very clever in that if you always make the lookup in the system nscd then the process with the alternative libc is decoupled from the system libc and all the system plugins required to answer the lookup request. Ludovic and I compared notes on the future of nscd, and we discussed a what-if scenario. What if we kept nscd, but removed all the caches, and left it as a daemon that could answer requests from system processes but the only goal was to decouple the libc required to service the request and the libc in the process? This is already starting to sound like Florian's getent idea where by a static process uses a known binary to carry out the NSS lookup and resolution [1]. What if instead of getent we just thinned down nscd to something we could audit and trust? If we really wanted to we could even compile the same code into getent as a fallback e.g. try nscd first (long lived) then getent (short lived). You might say "Well then nscd is mis-named!" I'd argue it's a "cache" for the shared objects and state required to do the lookup, but not the data itself, and if you didn't run nscd then you'd go through NSS normally, or "getent" if you were a statically compiled binary. Thoughts? -- Cheers, Carlos. [1] https://sourceware.org/legacy-ml/libc-alpha/2017-12/msg00831.html