Re: Another solution (was Re: All services that require a restart from
fredrik@liljegren.org (Fredrik Liljegren) wrote on 18.10.00 in <7w66mqfvo5.fsf@astral.paranormal.se>:
> Ben Collins <bcollins@debian.org> writes:
> > This brings up a good possible solution. Daemons can be required to link
> > to the static nss libs, assuming I compile that into the -dev package.
> > This means the modules would be static in the binary, and this breakage
> > would not occur.
>
> I think this is bloating the binaries. The idea with using shared
> libs is still to make a smaller fingerprint, load faster, having a
> smaller package on ftp etc, and I don't think it's worth leaving all
> that just because a restart of some daemons is hard to automize.
It's entirely the wrong solution anyway.
The main problem here is that NSS modules, just like Perl modules or
Apache modules or kernel modules, happen *at runtime* according to
configuration/scripting/whatever, and in fact that is the most important
design goal for them.
Going to static linking obviously defeats this design goal.
You can look at what Apache, Perl, and the kernel do to solve these
things, but I'm afraid all you'll find is that this problem is hard to
solve, and nobody seems to have figured out a good version to do it.
I think the best that could be done would be something along these lines:
* Figure out what type of application is affected. Say, anything that
calls the gethostbyaddr() function, or something along those lines.
* Figure out which executables are currently running. (HURD may lose
here.)
* Maybe make the same check a second or so later, so as to be able to
filter out most short-lived processes like ls.
* Analyze those executables (objdump is your friend ... be careful to
check you actually get the *running* version and not something that's
been replaced since) to find out if they use the API in question. (Is it
possible to make this work if the excutable loads modules that use those
APIs? I certainly don't know!)
* From the list of affected executables and processes, check if you
already know how to handle them. Tell the user about the rest.
And yes, that is a maximal solution. It may very well not be practical.
Now, as for avoiding the problem in the first place: that entails keeping
the relevant glibc interfaces stable. Everybody agrees this is a worthwile
goal, nearly everybody agrees it is not always possible, the rest is,
unfortunately, in the details.
MfG Kai
Reply to: