Używanie alternatywnego libc z hackami ld-linux.so; czystsza metoda?

Mam starszy system z bardzo starą biblioteką glibc, której nie możemy zaktualizować bez ponoszenia ogromnych prac związanych z testowaniem / sprawdzaniem poprawności.

Kilka razy musiałem uruchamiać w tym systemie nowsze programy (takie jak Java 1.7). Wybrałem rozwiązanie chroot, w którym pakuję wszystkie potrzebne biblioteki i uruchamiam usługę w chroot.

Chroot jest jednak bardzo ograniczający i wolałbym spróbować rozwiązać problem z LD_LIBRARY_PATH. Niestety libc.so.6: cannot handle TLS datapojawia się błąd, gdy próbuję tego.

Okazuje się, że potrzebuję /lib/ld-linux.so.2również chroota. To działa:

LD_LIBRARY_PATH=/home/chroot/lib /home/chroot/lib/ld-linux.so.2 /home/chroot/bin/program

Jednak javaudaremnia moją sztuczkę, sprawdzając, /proc/self/cmdlinegdzie należy załadować biblioteki, co kończy się niepowodzeniem, jeśli plik binarny nie został nazwany „bin / java”. Również Java wykonuje się podczas uruchamiania, co dodatkowo komplikuje sprawy.

W próbie ostatniej szansy dokonania tej pracy, otworzyłem binarnego java z edytorem hex i zastąpić ciąg /lib/ld-linux.so.2z /home/chroot/ld.so(i wykonane, że dowiązaniem do ld-linux.so.2), i to działa!

Ale myślę, że wszyscy zgodziliby się, że przerobienie ścieżki każdego nowego pliku binarnego na bezwzględną ścieżkę zagnieżdżonego systemu jest ogromną kludge.

Czy ktoś zna lepszy sposób korzystania z niestandardowej ścieżki biblioteki, w tym niestandardowej ld-linux.so?

dynamic-linking glibc patchelf

— bez danych
źródło

Ścieżka do modułu ładującego jest kompilowana do pliku binarnego w miarę odkrywania za pomocą edytora szesnastkowego. Rzeczywiście miał szczęście, że edytowanie binarny bezpośrednio pracował ponieważ oba /lib/ld-linux.so.2i /home/chroot/ld.sosą tej samej długości. Długości tych ciągów są również w formacie binarnym i możesz powodować subtelne problemy, jeśli bezpośrednio zmodyfikujesz ciągi.

Jeśli wybierzesz trasę, powinieneś rzucić okiem na coś takiego jak patchelf, aby zaktualizować interpreter. Pozwoli ci to na stałe i szybko zmienić tłumacza.

— gmjosack
źródło

To nie było szczęście, wiedziałem, że nie muszę przesuwać żadnego z bajtów ;-) Ale patchelf wygląda tak, jak chcę. Oprócz niemożności użycia ścieżki względnej, może również zająć się ścieżką LD_LIBRARY_PATH, której używam, aby nie potrzebował opakowania. Dam ci odpowiedź za odpowiedź, gdy tylko będę miał okazję ją przetestować.

— danych

To działa! To da mi przyzwoitą ścieżkę do miksowania nowych programów libc ze starymi programami libc na tym serwerze. Dla przyszłych czytelników polecenie brzmiało

patchelf --set-interpreter $JAVA/lib/ld-linux.so.2 --set-rpath $JAVA/lib:$JAVA/lib/i386:$JAVA/lib/i386/jli $JAVA/bin/java

: gdzie $ JAVA jest katalogiem środowiska JRE i gdzie zaokrągliłem wszystkie zależne biblioteki i umieściłem je w lib/katalogu środowiska JRE.

— danych

@ cóż bez danych nadal potrzebuję LD_LIBRARY_PATH, aby obejść ten libjvm.so, ponieważ libstdc ++. so.6: nie można otworzyć pliku obiektu współdzielonego: brak takiego pliku lub katalogu [root @ 97245bbe7cc1 tensorflow-java] #

— Amos

@Amos Minęło trochę czasu, ale w moim przypadku nie potrzebowałem już LD_LIBRARY_PATH, ponieważ domyślnie pochodzi z pliku binarnego java. Ale zwróć uwagę na część, w której powiedziałem, że obszedłem i znalazłem wszystkie biblioteki lib używane przez java i skopiowałem je do katalogu lib lib. Kiedyś ldd $JAVA/bin/javadostawałem ist. Są też takie dynamiczne, jak libnss.so

— danych