Niedawno natknąłem się na to odniesienie w proggit i (jak na razie) nie zostało to wyjaśnione.
Podejrzewam, że to może być to, ale nie jestem pewien.
Niedawno natknąłem się na to odniesienie w proggit i (jak na razie) nie zostało to wyjaśnione.
Podejrzewam, że to może być to, ale nie jestem pewien.
Odpowiedzi:
Jeśli ustawisz LD_PRELOAD
ścieżkę do obiektu współdzielonego, plik ten zostanie załadowany przed każdą inną biblioteką (w tym środowiskiem uruchomieniowym C libc.so
). Aby uruchomić ls
specjalną malloc()
implementację, wykonaj następujące czynności:
$ LD_PRELOAD=/path/to/my/malloc.so /bin/ls
LD_PRELOAD
. Powodem jest to, że jest to zmienna środowiskowa, dziedziczone przez procesy potomne - które mogą mieć inny katalog roboczy niż proces macierzysty. Dlatego żadna ścieżka względna nie zlokalizowałaby biblioteki do wstępnego załadowania.
Można zastąpić symbole w bibliotekach podstawowych, tworząc bibliotekę z tymi samymi symbolami i określając bibliotekę w LD_PRELOAD
.
Niektóre osoby używają go do określania bibliotek w niestandardowych lokalizacjach, ale LD_LIBRARY_PATH
jest to lepsze w tym celu.
Dzięki LD_PRELOAD
niemu możesz dać bibliotekom pierwszeństwo.
Na przykład możesz napisać bibliotekę, która implementuje malloc
i free
. I przez załadowanie ich ze LD_PRELOAD
swoim malloc
i free
zostanie wykonany zamiast standardowych.
calloc
? czy to by nie wszystko zepsuło?
malloc
i darmowe są specjalnie zaprojektowane w glibc, aby to umożliwić, a magazynie calloc
można zadzwonić do importowanego malloc
. Nie próbuj tego z innymi funkcjami. To nie zadziała tak dobrze.
Jak wiele osób wspomniało, używając LD_PRELOAD
do wstępnego załadowania biblioteki. BTW, można SPRAWDŹ , czy ustawienie jest dostępne przez ldd
komendę.
Przykład: załóżmy, że musisz wstępnie załadować własny libselinux.so.1
.
> ldd /bin/ls
...
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f3927b1d000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f3927914000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f392754f000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f3927311000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f392710c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3927d65000)
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f3926f07000)
Dlatego ustaw swoje środowisko ładowania wstępnego:
export LD_PRELOAD=/home/patric/libselinux.so.1
Sprawdź swoją bibliotekę jeszcze raz:
>ldd /bin/ls
...
libselinux.so.1 =>
/home/patric/libselinux.so.1 (0x00007fb9245d8000)
...
LD_PRELOAD
wyświetla listę bibliotek współdzielonych z funkcjami, które zastępują standardowy zestaw, podobnie jak /etc/ld.so.preload
robi to. Są one realizowane przez moduł ładujący /lib/ld-linux.so
. Jeśli chcesz zastąpić tylko kilka wybranych funkcji, możesz to zrobić, tworząc nadpisany plik obiektowy i ustawienie LD_PRELOAD
; funkcje w tym pliku obiektowym zastąpią tylko te funkcje, pozostawiając inne takie, jakie były.
Więcej informacji na temat bibliotek współdzielonych można znaleźć na stronie http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Oto szczegółowy post na blogu na temat wstępnego ładowania:
łatwo jest eksportować mylib.so
do env:
$ export LD_PRELOAD=/path/mylib.so
$ ./mybin
wyłączyć :
$ export LD_PRELOAD=
unset LD_PRELOAD
gdy używany jest LD_PRELOAD, plik ten zostanie załadowany przed jakąkolwiek inną
$export LD_PRELOAD=/path/lib
biblioteką lib, która ma zostać wstępnie załadowana, nawet tego można użyć w programach
Za pomocą LD_PRELOAD
ścieżki można zmusić moduł ładujący aplikacje do ładowania udostępnionego obiektu współdzielonego, ponad domyślny.
Deweloperzy używają tego do debugowania swoich aplikacji, udostępniając różne wersje współdzielonych obiektów.
Używaliśmy go do hakowania niektórych aplikacji, zastępując istniejące funkcje za pomocą przygotowanych obiektów współdzielonych.