Re: NSS ABI Stability

[Carlos O'Donell <carlos at redhat dot com>]

On 12/15/2016 03:49 AM, Alexander Kahl wrote:
> Could someone please elaborate on the ABI stability of glibc's NSS interface?

I'm CC'ing libc-alpha to get other key developer input from this.

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.

Detailed answer:
================

Let me apologize by saying we do a terrible job of documenting the NSS interface
for anyone other than glibc NSS experts to use.

You'd think we would have documented this better if we were going to create an
interface that other developers could adopt.

To be pedantic the entire interface is completely ABI stable because is relies only
on dlopen/dlsym and falls back to returning internal errors (NETDB_INTERNAL) if
specific required symbols can't be found in the service DSO that is being searched.
Generally this triggers the higher level NSS code to move on to the next service and
the error from the _last_ service in the chain is reported to the caller.

If a public supported API needs new functionality to support a given feature e.g.
a new flag that requires we do something different in the backend, then we may need
a new NSS function. We never reuse old functions since that would break ABI, but we
may require NSS modules to implement a new function for the new functionality to
work e.g. must implement _nss_*_gethostbyname4_r to do parallel A/AAAA queries,
otherwise we fall back to _nss_*_gethostbayname[23]_r. It is possible then that some
public high-level API calls might fail with old NSS modules that don't implement new
enough backend functions, but you will get an error for this that propagates up to
the caller. In this case the caller is in error because they made a call to an API
with a flag or feature request that is only supported on new enough glibc with new
enough NSS modules. In the end this is a system configuration problem.

A different question here is what is the "API stability" of the glibc NSS
interface. Exactly which functions are expected by a given version of glibc to
operate properly and how should such functions be implemented. That would allow you
to group a given glibc version with all the NSS modules that would be maximally
compatible and implement all the features such a glibc needs. We don't have that data.

> Nikolay (CC) and I are trying[1] to properly integrate third-party NSS modules
> into NixOS[2]. We'd like to share existing modules compiled against different
> versions of glibc.

You can do that. Nothing will crash. But if you use very very old modules with
very very new glibc, you might not get all the features supported and some
higher-level APIs will return errors.

Likewise you'd be doing something nobody else has ever tested which has bug-for-bug
compatibility issues.

> Is it a safe thing to do? What are the chances of modules breaking that way for
> updated versions of glibc?

We do not break modules on purpose. We only add new functions and test for them from
the NSS side to see if the module supports the new functionality.

> [1] https://github.com/NixOS/nixpkgs/pull/21150
> [2] http://nixos.org/

Hopefully this answers your questions.

-- 
Cheers,
Carlos.