NSS chroot protection

[Florian Weimer]

* Carlos O'Donell:

>> Should we revert the second part and keep loading new service modules?
>
> I dislike reverting the fix. It is natural to create a boundary between
> the configuration outside of the chroot and inside of the chroot.
>
> May I suggest a more radical approach?
>
> Load all the NSS service modules when the first modules is loaded,
> and keep the the fix in place?

It will likely break systems like dpkg and RPM, where NSS library
dependencies can be temporarily inconsistent during updates.  As long as
those NSS modules fail to load, nothing bad will happen, but if there
are crashes due to ABI mismatches exposed by ELF constructors, we have
introduced upgrade failures.  (Such failures can be very difficult to
recover from on RPM systems.)  This wouldn't be something that I'd feel
comfortable backporting.  Lazy loading tends to paper over these
problems because updates typically only need files data for system
accounts.

Loading an NSS module which depends on libpthread may also not be safe
for all processes.  With the current lazy loading scheme, we avoid some
bugs related to late loading of libpthread because many processes only
need dns or files, which do not depend on libpthread.

Thanks,
Florian