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.133.124]) by sourceware.org (Postfix) with ESMTPS id 1622B3858D20 for ; Tue, 1 Mar 2022 16:54:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1622B3858D20 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-614-JlCS34z7OhStbws0BRZiAw-1; Tue, 01 Mar 2022 11:54:22 -0500 X-MC-Unique: JlCS34z7OhStbws0BRZiAw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BA9D8FC80; Tue, 1 Mar 2022 16:54:20 +0000 (UTC) Received: from greed.delorie.com (ovpn-112-8.rdu2.redhat.com [10.10.112.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8CED61059591; Tue, 1 Mar 2022 16:54:06 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.15.2/8.15.2) with ESMTP id 221Gs44t194766; Tue, 1 Mar 2022 11:54:04 -0500 From: DJ Delorie To: "=?ISO-8859-1?Q?Ludovic_Court=E8s?=" Cc: carlos@redhat.com, ashankar@redhat.com, fweimer@redhat.com, adhemerval.zanella@linaro.org, libc-alpha@sourceware.org Subject: Re: On the removal of nscd from Fedora, and the future of nscd. In-Reply-To: =?ISO-8859-1?Q?<87czj682cp.fsf@gnu.org>_(message_from_Ludovi?= =?ISO-8859-1?Q?c_Court=E8s_on_Tue, _01_Mar_2022_10:10:46_+0100)?= Date: Tue, 01 Mar 2022 11:54:02 -0500 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Tue, 01 Mar 2022 16:54:27 -0000 Ludovic Courts writes: > 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 incompat= ible > libraries. My point is, if there's a risk that a Guix binary *could* load a host dso, then Guix is insufficiently isolated from the host system. nscd is just one example of how this could happen. If you accept this non-isolation, you need to accept that dsos need to be cross-usable. That Guix is accepting some sharing (like /etc/nsswitch.conf) but not all sharing (like libnss_*.so) opens Guix up to these types of problems, and thus, the onus is mostly on Guix to deal with them. Hence my feeling that "keep ncsd around because we're not isolated enough" is a weak (but still valid) reason to keep nscd. nscd is just the most obvious problem point, but not the only problem point. The right solution is to complete the isolation, although I admit that may be an impossible goal at this point. Note that I don't feel strongly about the above; just pointing it out.