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=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3423 invoked from network); 23 Oct 2020 13:29:32 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Oct 2020 13:29:32 -0000 Received: (qmail 7620 invoked by uid 550); 23 Oct 2020 13:29:28 -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 7602 invoked from network); 23 Oct 2020 13:29:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603459756; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ip+Ec/IdbLlOYn85QijHE0ehU5nYpA2VpQvB1v7AFFY=; b=Rsd9TnCyqLI/NRLmMy2tTNKk5pHhEZRmYlmQsgsBMI06yolZRdEE5fars43XZQMoMeMuW2 Ns5QOZ6DnCxJZaIEF0VPZDvq11GC/FB3vYcwosGRxOUBQ9NhKoShPgyVsLLVLtHwCGbNAb UREmDrXwP/Ao/YdgMoXnqgIlKpZPFe4= X-MC-Unique: D1hQRCm5PdGzHN9ZmnVlKA-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ip+Ec/IdbLlOYn85QijHE0ehU5nYpA2VpQvB1v7AFFY=; b=kA06xsveCWettKf6zNsTylEZXptdoMbaXMxOLZrAULQTZTw/G1A45P7aDB1xThSyK7 MuTVS7EqK2WmiV5hvArkzSfAY4mk4FREqYb0vb1LGrzQOpUO9/jnXmDiq5B/3arhH6Gh ycYCvzmMh37clbmQthDxq5AOszhdrsoPcC0SN+aKaE8uxwo33uA6RkbfAwdhV2qjB0tD HIGw1yBVIUmPeobnq+CCuhWKG92S0eiDMrABh/lbCOtuV1VD2TyUEl2IICKpu+Hi3CU+ EAp8M2YZt3/jyLSgjzM/KREmVD7VTjDVB5Lleusb2kuZ/DF3P7Dk5473w9YbcBTqCTUk ed/Q== X-Gm-Message-State: AOAM5327Df+m9d/evOz9DXrHU/Y0UoGorudLNygoZr+ECPfvkP9Ud50i p3itlqvyldEbZuNvrZkC9/bpNnLOXNJxOCc0p4kiJ4Zgs5FAlfNNRPdzKUvT8OUyz26RO5LrO9b /EAPPKcHonw7BPa422w== X-Received: by 2002:a05:620a:144c:: with SMTP id i12mr2157939qkl.492.1603459754328; Fri, 23 Oct 2020 06:29:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzbXiCBPZWQL/xYfYEdSGtOmdiq/arX557g+XGd/nOkfpn4BiHOALEdDb4U43BwirnRsy7rxw== X-Received: by 2002:a05:620a:144c:: with SMTP id i12mr2157911qkl.492.1603459753972; Fri, 23 Oct 2020 06:29:13 -0700 (PDT) To: Rich Felker , Arjun Shankar Cc: musl@lists.openwall.com, Florian Weimer References: <1924902939.18027073.1603105167534.JavaMail.zimbra@redhat.com> <805098991.18032044.1603106011330.JavaMail.zimbra@redhat.com> <20201020010855.GE17637@brightrain.aerifal.cx> From: Carlos O'Donell Organization: Red Hat Message-ID: Date: Fri, 23 Oct 2020 09:29:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <20201020010855.GE17637@brightrain.aerifal.cx> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=carlos@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [musl] Plans to remove nscd in Fedora On 10/19/20 9:08 PM, Rich Felker wrote: > On Mon, Oct 19, 2020 at 07:13:31AM -0400, Arjun Shankar wrote: >> Hi all, >> >> I am one of the maintainers for glibc in Fedora. We are planning to remove >> nscd from Fedora in the near future, targeting the Fedora 34 release [1]. >> >> Florian recently pointed out to me that this can impact users of musl-libc >> binaries since musl is nscd-aware. >> >> I can see that the Fedora musl-libc package has no "official" dependent >> packages (excepting musl-devel) in the Fedora repositories, but I expect >> that there might be packages/applications from out of the distribution and >> use cases that are affected by or possibly break with the removal of nscd. >> >> I'm writing to get some clarity on this. >> >> Best Regards, >> Arjun >> >> [1] WIP: https://fedoraproject.org/wiki/Changes/RemoveNSCD > > The only capacity in which musl uses nscd is to access custom > user/group backends provided through it. musl specifically does not > use nss itself because it's not compatible with static linking and > because loading arbitrary module libraries into the calling process's > core is not safe and goes against best practices. I believe the glibc > folks were starting to realize this too, so it was kinda my hope that > nscd would become the main/only way nss modules are accessed on glibc > too. 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). -- Cheers, Carlos.