Aaron Richton wrote:
> A few months back, I had issues with /usr/bin/passwd (which is linked
> against /usr/lib/libldap.so.5) getting confused by identically-named
> OpenLDAP symbols called via PAM. Rod Evans suggested linking OpenLDAP with
> -Bdirect, which worked great to fix this situation.
>
> But now I'm having issues with dtlogin calling out to PAM. rtc reports a
> bad free, but I can't reproduce it under watchmalloc nor umem. Quite
> honestly, I'm doubtful there's really a memory usage bug here. Rather, my
> current running theory is that I'm having allocator namespace issues from
> using the -Bdirect flag. When I run with LD_DEBUG=bindings, I see the
> following diff:
>
> [without direct linking]
> + 1: binding file=/usr/local/lib/liblber-2.3.so.0 to
> file=/usr/dt/lib/libSDtFwa.so.1: symbol `free'
> + 1: binding file=/usr/local/lib/liblber-2.3.so.0 to
> file=/usr/dt/lib/libSDtFwa.so.1: symbol `malloc'
>
> [with direct linking]
> - 1: binding file=/usr/local/lib/liblber-2.3.so.0 to file=/usr/lib/libc.so.1:
> symbol `free'
> - 1: binding file=/usr/local/lib/liblber-2.3.so.0 to file=/usr/lib/libc.so.1:
> symbol `malloc'
>
>
> Now, I don't want to turn off direct linking, because then I bring back
> the issue with /usr/bin/passwd. But dtlogin only seems to place nice with
> the libSDtFwa malloc, and -Bdirect stops that from being used.
>
> What can I try to confirm this theory, and if it's true, what can I try to
> get an object that works with /usr/bin/passwd and dtlogin simultaneously?
In my environment, Nevada, it looks like libSDtFwa.so.1 has been built
with -z interpose:
chaz 415. elfdump -d /usr/dt/lib/libSDtFwa.so.1
....
[26] FLAGS_1 0x400 [ OBJECT-INTERPOSE ]
This tags the library an explicit interposer. Explicit interposers are able
to "override" a direct binding. You might find lari(1) useful, as this tool
can analyze your bindings, for example:
chaz 423. lari /usr/dt/bin/dtlogin | egrep "alloc|free"
[3:0N]: free(): /lib/libc.so.1
[3:30ESI]: free(): /usr/dt/lib/libSDtFwa.so.1
[3:6EA]: free: /usr/dt/bin/dtlogin
[2:0N]: malloc(): /lib/libc.so.1
[2:30ESI]: malloc(): /usr/dt/lib/libSDtFwa.so.1
[2:0N]: realloc(): /lib/libc.so.1
[2:17EI]: realloc(): /usr/dt/lib/libSDtFwa.so.1
free/malloc/realloc have all been bound to libSDtFwa.so.1
(Ignore the 6 "bindings" to dltlogin for free - these are actually
the result of folks taking the address of free (&free), which is
a .plt offset. If you jumped to one of these bindings, you'd jump
to the .plt, which in turn would send you to libSDtFwa.so.1)
But, given that so many people do override the malloc family, we
also disabled them from being directly bound to:
chaz 428. elfdump -y /usr/lib/libc.so.1 | egrep "alloc|free"
[7] N realloc
[44] N free
[188] N malloc
The "N" means don't allow direct binding.
In theory, calls to the malloc family should fall back to the
default symbol lookup, and thus assuming libSDtFwa.so.1 is loaded
before libc, should bind to libSDtFwa.so.1 anyway.
Perhaps you don't have some of these "tricks" in your environment?
The rule to remember with direct bindings is that they protect again
"implicit" interposition. That's the whole point, you want to avoid
accidental interposition and bind directly to your intended target.
If you want interposition to occur in a direct binding environment,
then you must "explicitly" define the interposition. I'd recommend
reading the "Direct Bindings" Appendix of the SDX version of the
Linker and Libraries Manual for more details:
http://docs.sun.com/app/docs/doc/819-0690/aehzq?a=view
--
Rod.
