This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: NSS ABI Stability
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Alexander Kahl <ak at sodosopa dot io>, <libc-help at sourceware dot org>
- Cc: <nd at arm dot com>, Nikolay Amiantov <ab at fmap dot me>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 16 Dec 2016 10:59:51 +0000
- Subject: Re: NSS ABI Stability
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <87mvfxfulm.fsf@pazuzu.in.sodosopa.io> <ac742e1d-7421-d5d8-b01b-ae46bfbbeb48@redhat.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 16/12/16 02:00, Carlos O'Donell wrote:
> On 12/15/2016 03:49 AM, Alexander Kahl wrote:
>> Could someone please elaborate on the ABI stability of glibc's NSS interface?
>
> TLDR; You can mix any NSS modules you want with any version of glibc. The dlopen
> and dlsym interface used isolates you from ABI issues. The API issues that
> result could be problematic though, and some features could return errors if
> the underlying NSS service module DSOs don't implement the required low-level
> functions required by the high-level APIs.
i've seen dlopen of a new libnss_dns fail because it depends on
libresolv and the libc was too old to load a newer libresolv
(causing name lookup failures on a live system after a libc update).
>> [1] https://github.com/NixOS/nixpkgs/pull/21150
in general it is not possible to update glibc safely because it
consists of multiple shared libs without stable abi between them
and the update cannot be done atomically, with runtime loaded
components even atomic file system update does not help: existing
process with old libc may load a new libc component after the
update (even if the loaded module has stable abi, it may depend
on a not yet loaded libc component that does not).
the safe way to implement extensible libc behaviour is to have it
in a separate component (daemon) with stable interface (name lookup
protocol) that survives independent updates of the two sides
(you only need to make sure that the daemon is not loading libc
components during libc update and that it can reexec itself without
dropping connections for daemon update).
i don't know how hard this is to do with nscd, but currently the
only hope to have a system with safe live update and nss is via
glibc nscd on a musl libc based system (musl is safe to update).
which is a long way to say that i think nss modules should support
nscd and sssd should be fixed to work with it.