From: Tim Tassonis <stuff@decentral.ch>
To: musl@lists.openwall.com
Subject: Re: [musl] Plans to remove nscd in Fedora
Date: Fri, 23 Oct 2020 14:01:00 +0200 [thread overview]
Message-ID: <514e3157-f82b-8417-e748-16e9539ecacd@decentral.ch> (raw)
In-Reply-To: <87pn59i38j.fsf@oldenburg2.str.redhat.com>
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
next prev parent reply other threads:[~2020-10-23 12:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1924902939.18027073.1603105167534.JavaMail.zimbra@redhat.com>
2020-10-19 11:13 ` Arjun Shankar
2020-10-20 1:08 ` Rich Felker
2020-10-23 11:35 ` Florian Weimer
2020-10-23 12:01 ` Tim Tassonis [this message]
2020-10-23 12:09 ` Florian Weimer
2020-10-23 13:29 ` Carlos O'Donell
2020-10-23 13:37 ` Laurent Bercot
2020-10-23 14:14 ` Jesse Hathaway
2020-10-23 16:58 ` Rich Felker
2020-10-26 12:20 ` Florian Weimer
2020-10-26 13:12 ` Rich Felker
2020-11-02 13:54 ` Florian Weimer
2020-11-02 14:50 ` Rich Felker
2020-11-03 9:07 ` Florian Weimer
2020-11-03 15:41 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=514e3157-f82b-8417-e748-16e9539ecacd@decentral.ch \
--to=stuff@decentral.ch \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).