This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: symbol name space issues with NSS modules
- From: Pedro Alves <palves at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Thorsten Kukuk <kukuk at suse dot de>, libc-alpha at sourceware dot org
- Date: Sat, 9 Apr 2016 12:45:35 +0100
- Subject: Re: symbol name space issues with NSS modules
- Authentication-results: sourceware.org; auth=none
- References: <20160404134356 dot GA20216 at suse dot de> <5702780D dot 7070208 at redhat dot com> <20160404142237 dot GA20583 at suse dot de> <57062C77 dot 1080103 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1604071516070 dot 26336 at digraph dot polyomino dot org dot uk> <20160408183921 dot 4FAAF2C3B21 at topped-with-meat dot com> <57080B62 dot 7070206 at redhat dot com> <20160408230727 dot 8E17C2C3B18 at topped-with-meat dot com>
On 04/09/2016 12:07 AM, Roland McGrath wrote:
> This morass might lead one to want to use dynamic linking name spaces
> (dlmopen) for NSS modules. But that is its own whole can of worms
> that might well wind up being worse in totally different ways.
ISTR some work a while ago to improve dlmopen support, make it
match Solaris behavior more closely. Seems like it'd be the
ideal solution.
Alternatively, in the "always possible to solve with indirection" vein,
fork and load third-party modules in a separate process, with some
simple RPC to return results back to parent.
>
>> AFAICS, gdb has not renamed the symbol, and I'm not the one
>> who tripped on it in the first place, so I'm not sure
>> whether this particular instance of the bug was fixed some
>> other way.
>
> The symbol timeval_add does not appear anywhere in the libc sources,
> including ChangeLog files. So I tend to doubt that this symbol name
> was used by any libc code in the past either. That suggests that the
> case you hit was in a third-party NSS module. Obviously we can't
> ourselves do anything directly about the quality of third-party
> modules. But we could potentially provide a tool to vet third-party
> modules for our name space rules.
The original report showed:
#0 timeval_add (result=0x7fffffffd850, a=0x0, b=0x3d090) at ../../libiberty/timeval-utils.c:57
#1 0x0000003d78a0f124 in timeval_current_ofs () from /lib64/libsamba-util.so.0
#2 0x0000003d71e12b84 in name_query () from /usr/lib64/samba/libgse.so
#3 0x00007ffff0d3d489 in _nss_wins_gethostbyname_r () from /lib64/libnss_wins.so.2
#4 0x0000003d3ad0ebd3 in gethostbyname_r@@GLIBC_2.2.5 () from /lib64/libc.so.6
#5 0x0000003d3ad0e316 in gethostbyname () from /lib64/libc.so.6
...
Frame #0 is GDB's symbol, which is what overrode a symbol of the same
name in libsamba-util.so.0. On Fedora 23, I still see the same symbols
as the OP saw.
$ readelf -s /lib64/libsamba-util.so.0 | grep timeval_add
534: 000000000000ed20 63 FUNC GLOBAL DEFAULT 12 timeval_add@@SAMBA_UTIL_0.0.1
$ readelf -s /lib64/libnss_wins.so.2 | grep gethostbyname_r
36: 0000000000001040 1435 FUNC GLOBAL DEFAULT 12 _nss_wins_gethostbyname_r@@NSS_WINS_2
libnss_wins.so.2 is provided by:
$ rpm -qf /lib64/libnss_wins.so.2
samba-winbind-modules-4.3.6-0.fc23.x86_64
I already had those installed, most probably just because I installed
Samba.
I don't know how to make gethostname end up calling into this
wins nss module. It doesn't for me, but I assume that remote debugging
with gdb is still broken for anyone for who it does. All it takes to
get to that gethostname call is "target remote <host>:<port>".
Thanks,
Pedro Alves