This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: NSS ABI Stability

Hi Carlos,

First of all, let me thank you for this truly elaborate answer. I wish
the official NSS documentation was as good as your remarks.

Carlos O'Donell writes:

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

So if I understand correctly, NSS won't break completely, but a failing
NSS module might cause unexpected behavior by not working when it's
expected to. Fair enough.

> Detailed answer:
> ================
> [...]
> 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.

Interesting! I've asked myself what's the difference between those one
time in the past.

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

I wonder - is the same true if the potentially outdated NSS module in
question is loaded by nscd, instead?

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

We decided to use a different approach where nscd will always be used to
load third-party NSS modules, otherwise we'd have to patch glibc to look
for NSS modules in a custom location, which is a problem very specific
to NixOS. Of course, this always means nscd's respective glibc version
will be the one NSS modules will be used, against.

Do you see any problems with this?
The only thing I could make out so far is that in one particular use
case I'm interested in, enabling SSSD through its NSS module, requires
nscd's user and group caching to be switched off.
If you can add anything, please let me know.

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

That's really good to know.

> Hopefully this answers your questions.

Well, mostly :)

Attachment: signature.asc
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]