Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 23 Oct 2020 14:01:00 +0200
From: Tim Tassonis <stuff@...entral.ch>
To: musl@...ts.openwall.com
Subject: Re: Plans to remove nscd in Fedora



On 10/23/20 1:35 PM, Florian Weimer wrote:
> * Rich Felker:
> 
>> The only capacity in which musl uses nscd is to access custom
>> user/group backends provided through it.
> 
> And that's the only way to get this data into musl programs.
> 
>> 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.
> 
> This requirement has largely been pushed into the NSS modules
> themselves.  If they do more than just opening a files or sockets, they
> need to offload part of the functionality (actually most of it) into a
> separate daemon.  This is the difference between nss_ldap and nss_ldapd.
> 
> SSSD has largely assumed this role for the non-hosts maps.  It looks
> like that systemd-resolved will cover the hosts maps.  So it's unclear
> what's left for nscd to handle.

You might not know about this, but there is actually a world beyond 
Redhat/Fedora/Systemd. Not that I am advocating for nscd to remain, but 
I'm not sure this is the right list to place advertisement for your 
great RedHat products.

Bye
Tim

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.