mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] Plans to remove nscd in Fedora
       [not found] <1924902939.18027073.1603105167534.JavaMail.zimbra@redhat.com>
@ 2020-10-19 11:13 ` Arjun Shankar
  2020-10-20  1:08   ` Rich Felker
  0 siblings, 1 reply; 15+ messages in thread
From: Arjun Shankar @ 2020-10-19 11:13 UTC (permalink / raw)
  To: musl; +Cc: Florian Weimer, Carlos O'Donell

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  2020-10-19 11:13 ` [musl] Plans to remove nscd in Fedora Arjun Shankar
@ 2020-10-20  1:08   ` Rich Felker
  2020-10-23 11:35     ` Florian Weimer
  2020-10-23 13:29     ` Carlos O'Donell
  0 siblings, 2 replies; 15+ messages in thread
From: Rich Felker @ 2020-10-20  1:08 UTC (permalink / raw)
  To: Arjun Shankar; +Cc: musl, Florian Weimer, Carlos O'Donell

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.

Rich

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  2020-10-20  1:08   ` Rich Felker
@ 2020-10-23 11:35     ` Florian Weimer
  2020-10-23 12:01       ` Tim Tassonis
  2020-10-23 13:29     ` Carlos O'Donell
  1 sibling, 1 reply; 15+ messages in thread
From: Florian Weimer @ 2020-10-23 11:35 UTC (permalink / raw)
  To: Rich Felker; +Cc: Arjun Shankar, musl, Carlos O'Donell

* 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.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  2020-10-23 11:35     ` Florian Weimer
@ 2020-10-23 12:01       ` Tim Tassonis
  2020-10-23 12:09         ` Florian Weimer
  0 siblings, 1 reply; 15+ messages in thread
From: Tim Tassonis @ 2020-10-23 12:01 UTC (permalink / raw)
  To: musl



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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  2020-10-23 12:01       ` Tim Tassonis
@ 2020-10-23 12:09         ` Florian Weimer
  0 siblings, 0 replies; 15+ messages in thread
From: Florian Weimer @ 2020-10-23 12:09 UTC (permalink / raw)
  To: Tim Tassonis; +Cc: musl

* Tim Tassonis:

> 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.

Yes, we know that.  Which is why Arjun reached out to you.  Was this a
mistake?  Is the musl community not interested in compatibility with
Fedora and its downstream distributions?

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  2020-10-20  1:08   ` Rich Felker
  2020-10-23 11:35     ` Florian Weimer
@ 2020-10-23 13:29     ` Carlos O'Donell
  2020-10-23 13:37       ` Laurent Bercot
  2020-10-23 14:14       ` Jesse Hathaway
  1 sibling, 2 replies; 15+ messages in thread
From: Carlos O'Donell @ 2020-10-23 13:29 UTC (permalink / raw)
  To: Rich Felker, Arjun Shankar; +Cc: musl, Florian Weimer

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.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  2020-10-23 13:29     ` Carlos O'Donell
@ 2020-10-23 13:37       ` Laurent Bercot
  2020-10-23 14:14       ` Jesse Hathaway
  1 sibling, 0 replies; 15+ messages in thread
From: Laurent Bercot @ 2020-10-23 13:37 UTC (permalink / raw)
  To: musl, Rich Felker, Arjun Shankar; +Cc: Florian Weimer


>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).

  There is such an approach already:
  https://skarnet.org/software/nsss/

  It works, it just has not been integrated into distributions yet
because musl distributions, at the moment, are not much interested in
NSS functionality, and glibc distributions simply use nsswitch.
  If there is interest, I'll be happy to cooperate with any relevant
project to make sure it's suited to its needs.

--
  Laurent


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  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
  1 sibling, 2 replies; 15+ messages in thread
From: Jesse Hathaway @ 2020-10-23 14:14 UTC (permalink / raw)
  To: musl; +Cc: Rich Felker, Arjun Shankar, Florian Weimer

On Fri, Oct 23, 2020 at 8:29 AM Carlos O'Donell <carlos@redhat.com> wrote:
> 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).

Given the increasing prevalence of statically deployed programs from languages
such as C, Go, Rust, and even Haskell. I would love to see continued
distribution support for querying NSS from these programs. An nscd variant
without caching seems like a good approach, but I think it would be unfortunate
to remove nscd from distributions before an alternative approach was available.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  2020-10-23 14:14       ` Jesse Hathaway
@ 2020-10-23 16:58         ` Rich Felker
  2020-10-26 12:20         ` Florian Weimer
  1 sibling, 0 replies; 15+ messages in thread
From: Rich Felker @ 2020-10-23 16:58 UTC (permalink / raw)
  To: Jesse Hathaway; +Cc: musl, Arjun Shankar, Florian Weimer, Carlos O'Donell

On Fri, Oct 23, 2020 at 09:14:01AM -0500, Jesse Hathaway wrote:
> On Fri, Oct 23, 2020 at 8:29 AM Carlos O'Donell <carlos@redhat.com> wrote:
> > 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).
> 
> Given the increasing prevalence of statically deployed programs from languages
> such as C, Go, Rust, and even Haskell. I would love to see continued
> distribution support for querying NSS from these programs. An nscd variant
> without caching seems like a good approach, but I think it would be unfortunate
> to remove nscd from distributions before an alternative approach was available.

Yes! As Laurent also noted, the real value here is maintaining the
continuity of having a common, widely-deployed protocol and interface
to perform NSS queries over. This doesn't necessitate keeping nscd
permanently but does mean it should be removed only at the same time a
replacement is deployed.

Rich

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  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
  1 sibling, 1 reply; 15+ messages in thread
From: Florian Weimer @ 2020-10-26 12:20 UTC (permalink / raw)
  To: Jesse Hathaway; +Cc: musl, Rich Felker, Arjun Shankar

* Jesse Hathaway:

> On Fri, Oct 23, 2020 at 8:29 AM Carlos O'Donell <carlos@redhat.com> wrote:
>> 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).
>
> Given the increasing prevalence of statically deployed programs from
> languages such as C, Go, Rust, and even Haskell.  I would love to see
> continued distribution support for querying NSS from these
> programs. An nscd variant without caching seems like a good approach,
> but I think it would be unfortunate to remove nscd from distributions
> before an alternative approach was available.

But Go and Haskell are really old by now, and nscd support hasn't landed
in those language run-times (and their de-facto default
implementations).  After ten to thrity years of waiting, is it still
reasonable to expect that this might happen.

Even for C, there is no push to make nscd a mandatory installation
requirement once the system uses services beyond the “dns” and “files”
modules.  I would have expected to see a development in this direction
by now there as well.  It's not just that we have turned down such
requests, they did not even happen.

I suspect it's just that users that have large databases under /etc or
require on remote integration have little interest in static linking and
vice versa.

An added complication is that a model involving a separate daemon does
not work well for containers.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  2020-10-26 12:20         ` Florian Weimer
@ 2020-10-26 13:12           ` Rich Felker
  2020-11-02 13:54             ` Florian Weimer
  0 siblings, 1 reply; 15+ messages in thread
From: Rich Felker @ 2020-10-26 13:12 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Jesse Hathaway, musl, Arjun Shankar, Carlos O'Donell

On Mon, Oct 26, 2020 at 01:20:23PM +0100, Florian Weimer wrote:
> * Jesse Hathaway:
> 
> > On Fri, Oct 23, 2020 at 8:29 AM Carlos O'Donell <carlos@redhat.com> wrote:
> >> 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).
> >
> > Given the increasing prevalence of statically deployed programs from
> > languages such as C, Go, Rust, and even Haskell.  I would love to see
> > continued distribution support for querying NSS from these
> > programs. An nscd variant without caching seems like a good approach,
> > but I think it would be unfortunate to remove nscd from distributions
> > before an alternative approach was available.
> 
> But Go and Haskell are really old by now, and nscd support hasn't landed
> in those language run-times (and their de-facto default
> implementations).  After ten to thrity years of waiting, is it still
> reasonable to expect that this might happen.
> 
> Even for C, there is no push to make nscd a mandatory installation
> requirement once the system uses services beyond the “dns” and “files”
> modules.  I would have expected to see a development in this direction
> by now there as well.  It's not just that we have turned down such
> requests, they did not even happen.

It's not mandatory on glibc, but it's a widely deployed existing
interface on most "big" systems, and it's easy to add with a quick
apt-get or whatever on others if you find you need it for integration
with non-glibc binaries. If it remains easy to add, having it not
installed by default is really not a big deal, but I kinda worry about
bitrot/breakage from suddenly having far fewer users.

> I suspect it's just that users that have large databases under /etc or
> require on remote integration have little interest in static linking and
> vice versa.

It's not that they have interest in static linking. It's that
providers of applications who want a binary that "runs anywhere" do.

FWIW its presence would also let you fix the issue of lookups from
(truely-, not mostly-) static-linked glibc programs not working right,
just by goind to nscd first when it's present.

> An added complication is that a model involving a separate daemon does
> not work well for containers.

Sure it does. The daemon containerizes just like everything else.
Whether the host outside the container is using nscd is irrelevant to
the guest inside, and vice versa. Typically inside containers you
*don't* want to integrate with big shared user identities somewhere
outside, but you can if you want.

Rich

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  2020-10-26 13:12           ` Rich Felker
@ 2020-11-02 13:54             ` Florian Weimer
  2020-11-02 14:50               ` Rich Felker
  0 siblings, 1 reply; 15+ messages in thread
From: Florian Weimer @ 2020-11-02 13:54 UTC (permalink / raw)
  To: Rich Felker; +Cc: Jesse Hathaway, musl, Arjun Shankar, Carlos O'Donell

* Rich Felker:

> It's not mandatory on glibc, but it's a widely deployed existing
> interface on most "big" systems, and it's easy to add with a quick
> apt-get or whatever on others if you find you need it for integration
> with non-glibc binaries.

This has not been true for quite a few years because using nscd along
with sssd for the same databases is not supported (sssd is where all the
domain integration work happens these days):

<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/usingnscd-sssd>

SUSE also recommends disabling parts of nscd:

| -  Modify  /etc/nscd.conf
| 
| enable-cache   passwd    no
| enable-cache   group      no

<https://www.suse.com/support/kb/doc/?id=000019039>

I think SUSE has largely switched to SSSD as well for the most recent
product releases, but I do not have much insight into their work
unfortunately.

> If it remains easy to add, having it not installed by default is
> really not a big deal,

(we have been in this situation for many, many years)

> but I kinda worry about bitrot/breakage from suddenly having far fewer
> users.

nscd is already very broken and has issues with workloads that trigger
many cache misses.

>> I suspect it's just that users that have large databases under /etc or
>> require on remote integration have little interest in static linking and
>> vice versa.
>
> It's not that they have interest in static linking. It's that
> providers of applications who want a binary that "runs anywhere" do.

In my world, they tend to either not integrate NSS at all (if they are
written in Go) or dynamically link against glibc 2.12 or even older.

> FWIW its presence would also let you fix the issue of lookups from
> (truely-, not mostly-) static-linked glibc programs not working right,
> just by goind to nscd first when it's present.

It would still require changes to nscd: support for all databases,
pass-through of uncached lookups that cannot be switched off (at present
caching cannot be controlled independently), and of course tons of bug
fixes.

>> An added complication is that a model involving a separate daemon does
>> not work well for containers.
>
> Sure it does. The daemon containerizes just like everything else.
> Whether the host outside the container is using nscd is irrelevant to
> the guest inside, and vice versa. Typically inside containers you
> *don't* want to integrate with big shared user identities somewhere
> outside, but you can if you want.

The problem are images which have just one application in them and lack
full init running as PID 1 in the container.  For such images, you can't
simply add a configuration file that causes nscd to launch, you'd
actually have to patch the application to do that.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  2020-11-02 13:54             ` Florian Weimer
@ 2020-11-02 14:50               ` Rich Felker
  2020-11-03  9:07                 ` Florian Weimer
  0 siblings, 1 reply; 15+ messages in thread
From: Rich Felker @ 2020-11-02 14:50 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Jesse Hathaway, musl, Arjun Shankar, Carlos O'Donell

On Mon, Nov 02, 2020 at 02:54:31PM +0100, Florian Weimer wrote:
> * Rich Felker:
> 
> > It's not mandatory on glibc, but it's a widely deployed existing
> > interface on most "big" systems, and it's easy to add with a quick
> > apt-get or whatever on others if you find you need it for integration
> > with non-glibc binaries.
> 
> This has not been true for quite a few years because using nscd along
> with sssd for the same databases is not supported (sssd is where all the
> domain integration work happens these days):
> 
> <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/usingnscd-sssd>
> 
> SUSE also recommends disabling parts of nscd:
> 
> | -  Modify  /etc/nscd.conf
> | 
> | enable-cache   passwd    no
> | enable-cache   group      no
> 
> <https://www.suse.com/support/kb/doc/?id=000019039>
> 
> I think SUSE has largely switched to SSSD as well for the most recent
> product releases, but I do not have much insight into their work
> unfortunately.
> 
> > If it remains easy to add, having it not installed by default is
> > really not a big deal,
> 
> (we have been in this situation for many, many years)
> 
> > but I kinda worry about bitrot/breakage from suddenly having far fewer
> > users.
> 
> nscd is already very broken and has issues with workloads that trigger
> many cache misses.

Thanks for filling me in on the status of this. Perhaps
https://github.com/pikhq/musl-nscd (not part of musl, but by a
long-time contributor) would be a useful basis for building a
replacement glibc systems could use too?

Rich

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  2020-11-02 14:50               ` Rich Felker
@ 2020-11-03  9:07                 ` Florian Weimer
  2020-11-03 15:41                   ` Rich Felker
  0 siblings, 1 reply; 15+ messages in thread
From: Florian Weimer @ 2020-11-03  9:07 UTC (permalink / raw)
  To: Rich Felker; +Cc: Jesse Hathaway, musl, Arjun Shankar, Carlos O'Donell

* Rich Felker:

> Thanks for filling me in on the status of this. Perhaps
> https://github.com/pikhq/musl-nscd (not part of musl, but by a
> long-time contributor) would be a useful basis for building a
> replacement glibc systems could use too?

There is also unscd: <https://busybox.net/~vda/unscd/>
It covers fewer maps, though.

For a full solution, we would need something that can deal (correctly)
with the shadow database.  That's currently always in-process because we
rely on the permissions of the calling process.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [musl] Plans to remove nscd in Fedora
  2020-11-03  9:07                 ` Florian Weimer
@ 2020-11-03 15:41                   ` Rich Felker
  0 siblings, 0 replies; 15+ messages in thread
From: Rich Felker @ 2020-11-03 15:41 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Jesse Hathaway, musl, Arjun Shankar, Carlos O'Donell

On Tue, Nov 03, 2020 at 10:07:23AM +0100, Florian Weimer wrote:
> * Rich Felker:
> 
> > Thanks for filling me in on the status of this. Perhaps
> > https://github.com/pikhq/musl-nscd (not part of musl, but by a
> > long-time contributor) would be a useful basis for building a
> > replacement glibc systems could use too?
> 
> There is also unscd: <https://busybox.net/~vda/unscd/>
> It covers fewer maps, though.
> 
> For a full solution, we would need something that can deal (correctly)
> with the shadow database.  That's currently always in-process because we
> rely on the permissions of the calling process.

Shadow was discussed when this was written, and was deemed outside the
scope for the intended goal of enabling access to centralized user
databases. As far as we could tell (at least as I remember), existing
systems aren't using shadow this way, and if passwords are being
centrally managed at all (and if they're used at all), they could just
be distributed through getpw*() only to authorized clients. Still,
shadow support could be useful for alternate local backends (like the
tcb shadow support musl has internally, or shadow-in-homedir).

The bigger omission is probably hosts and all the other obscure
databases. musl does not use nscd protocol for hosts because dns was
deemed a better existing protocol for bridging hostname lookups to
arbitrary backends, and the nscd protocol was deemed deficient for
offering additional functionality beyond what dns could offer (e.g. it
can't represent scope ids for link-local results).

Rich

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2020-11-03 15:41 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1924902939.18027073.1603105167534.JavaMail.zimbra@redhat.com>
2020-10-19 11:13 ` [musl] Plans to remove nscd in Fedora Arjun Shankar
2020-10-20  1:08   ` Rich Felker
2020-10-23 11:35     ` Florian Weimer
2020-10-23 12:01       ` Tim Tassonis
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

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ http://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git