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