????? ???????????? wrote:
> Can I break the libc symbol protection without marking my libraries as
> interposers?
A large number of interfaces within libc have been tagged as
protected. This ensures libc is pre-bound to these symbols
at link-edit time, and results in libc being "self-contained"
(ie. libc.so.1 doesn't need ld.so.1 to resolve references to
these symbols at runtime). This is necessary for much of
libc's processing, as it runs critical code that can be
compromised by ld.so.1 processing, and the interposition
or auditing that ld.so.1 would allow.
However, a number of routines that are known to be popular
interposition candidates have been left as global (not
protected). Although libc still directly binds to these
symbols, this direct binding can be overridden with LD_NODIRECT
or by establishing an interposer.
elfdump(1) can reveal a symbols visibility. For example,
% elfdump -sN.dynsym /lib/libc.so.1
....
[559] 0x000b7d88 0x00000012 FUNC GLOB P 37 .text mutex_lock
shows that mutex_lock is protected ("P"). Where as:
[1358] 0x0004bdff 0x00000042 FUNC GLOB D 40 .text getenv
getenv had default ("D") global binding.
By default, libc will bind to it's own version of getenv. But
LD_NODIRECT can be used to affect this binding:
% cat xxx.c
#include <stdio.h>
char *getenv()
{
return (NULL);
}
void main() {}
% cc -o xxx xxx.c
% LD_DEBUG=bindings ./xxx 2>&1 | fgrep getenv
25309: binding file=/lib/libc.so.1 to file=/lib/libc.so.1: symbol `getenv'
% LD_NODIRECT=yes LD_DEBUG=bindings ./xxx 2>&1 | fgrep getenv
25311: binding file=/lib/libc.so.1 to file=xxx: symbol `getenv'
Perhaps you could tell us exactly what you are trying to do?
--
Rod
Everybody to Everest!
April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for
The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit
www.everestchallenge.kintera.org/rie to show your support. Thanks!
