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ć lsspecjalną 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_PATHjest to lepsze w tym celu.
Dzięki LD_PRELOADniemu możesz dać bibliotekom pierwszeństwo.
Na przykład możesz napisać bibliotekę, która implementuje malloci free. I przez załadowanie ich ze LD_PRELOADswoim malloci freezostanie wykonany zamiast standardowych.
calloc? czy to by nie wszystko zepsuło?
malloci darmowe są specjalnie zaprojektowane w glibc, aby to umożliwić, a magazynie callocmoż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_PRELOADdo wstępnego załadowania biblioteki. BTW, można SPRAWDŹ , czy ustawienie jest dostępne przez lddkomendę.
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_PRELOADwyświetla listę bibliotek współdzielonych z funkcjami, które zastępują standardowy zestaw, podobnie jak /etc/ld.so.preloadrobi 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.sodo 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/libbiblioteką 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.