The Samba-Bugzilla – Bug 1360
libnss_wins.so pollutes namespace
Last modified: 2005-08-24 10:16:05 UTC
Since libnss_wins.so is meant to be dynamically loaded into many other programs,
it should avoid using function names that may collide with names that other
programs might want to use.
For example, having wins as a hostname resolution method in my
/etc/nsswitch.conf caused my elinks web browser to crash. (See the attached URL
for details.) In short, elinks contains a function called convert_string(),
which causes libnss_wins.so to segfault because libnss_wins.so calls elinks's
convert_string() instead of its own.
There are many many potential land-mine symbols like that in libnss_wins.so,
such as add_suffix, align_string, allow_access, become_daemon, close_sock,
file_save, etc. Any of them could cause unpredictable breakage in any program
that performs hostname lookups!
Contrast this with most of my other libnss_* libraries on my system, which don't
define many symbols, and those that are defined have nice long names that are
unlikely to clash with anything.
It might be a rather large undertaking to properly clean up the namespace of
libnss_wins.so, but it is possible to easily mitigate its effects by linking the
shared library with a -Bsymbolic flag. Using -Bsymbolic changes the runtime
symbol lookup order to first look in libnss_wins.so itself before looking
elsewhere. I believe that that is the desired behavior, and should be used on
all platforms that support it. By linking libnss_wins.so with -Bsymbolic, I was
able to run elinks without errors despite the clash of the convert_string()
Created attachment 517 [details]
Link shared libraries using -Bsymbolic
This mitigates namespace clash problems for me (on Fedora Core 2). I'll leave
it to those who have more experience than I to propagate the fix to other
platforms with the appropriate automake magic.
Could I get a comment on the -Bsymbolic change please? Any reason why it
shouldn't be added (at least for Linux)?
Great idea - I've checked it in for linux.
My suggested patch was applied incorrectly to the source. You need to pass
-Wl,-Bsymbolic to gcc so that it will invoke ld with the -Bsymbolic flag. The
source code is missing the -Wl, part.
To gcc, the naked -B option specifies the path where gcc should look for its
supporting files. Therefore the botched patch has no effect, so I'm re-opening
Doh - my fault. I should have actually applied the patch and not done it by
hand. Sorry. Hopefully it should be OK now.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.