W jakiej kolejności dynamiczny linker Linuksa szuka ścieżek?

To nie jest duplikat, ponieważ dotyczy osobliwości, którą zauważyłem, gdy używam /etc/ld.so.conf.

Aby uzyskać ścieżki, w których dynamiczny linker szuka bibliotek, uruchamiam polecenie ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g". Kiedy /etc/ld.so.confnie ma na nim żadnych ścieżek. Dane wyjściowe z poprzedniego polecenia to

/lib
/usr/lib

Uznałem, że /libnajpierw szuka, a potem /usr/lib. Gdy dodam nową ścieżkę, taką jak /usr/local/lib, do, /etc/ld.so.confa następnie przerób /etc/ld.so.cache, dane wyjściowe ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"stają się

/usr/local/lib
/lib
/usr/lib

Uważam to za dziwne, ponieważ jeśli mam rację, że kolejność przeszukiwania wymienionych katalogów jest od góry do dołu, wówczas dodatkowe katalogi są przeszukiwane przed /libi /usr/lib. To, że dodatkowe katalogi są przeszukiwane, zanim zaufane katalogi same w sobie nie jest dziwne, ale kiedy /libjest przeszukiwane wcześniej /usr/lib, jest to dziwne, ponieważ /bin& /sbinsą wyszukiwane po /usr/bin& /usr/sbinin PATH.

Nawet jeśli ścieżki wymienione przez ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"byłyby przeszukiwane od dołu do góry, nadal byłoby to skośne porządkowanie, ponieważ dodatkowe katalogi byłyby przeszukiwane po zaufanych, podczas gdy /libbyłyby przeszukiwane /usr/lib.

Więc w jakiej kolejności ld.sowyszukiwane są ścieżki bibliotek? Dlaczego jest /libprzeszukiwany wcześniej /usr/lib? Jeśli tak nie jest, to dlaczego wyszukiwane są dodatkowe katalogi /lib?

Kolejność jest udokumentowana w instrukcji dynamicznego linkera, czyli ld.so. To jest:

1. katalogi z LD_LIBRARY_PATH;
2. katalogi z /etc/ld.so.conf;
3. /lib;
4. /usr/lib.

(Trochę upraszczam, szczegółowe informacje można znaleźć w instrukcji).

Kolejność ma sens, gdy weźmiesz pod uwagę, że jest to jedyny sposób na zastąpienie biblioteki w domyślnej lokalizacji biblioteką niestandardową. LD_LIBRARY_PATHjest ustawieniem użytkownika, musi nadejść przed innymi. /etc/ld.so.confjest ustawieniem lokalnym, pojawia się przed domyślnym systemem operacyjnym. Więc jako użytkownik, jeśli chcę uruchomić program z inną wersją biblioteki, mogę uruchomić program LD_LIBRARY_PATHzawierający lokalizację tej innej wersji biblioteki. A jako administrator, mogę umieścić inną wersję biblioteki w /usr/local/libi listy /usr/local/libw /etc/ld.so.conf.

Zaufanie nie wchodzi w to. Dowolny katalog wymieniony na tej ścieżce wyszukiwania musi być zaufany, ponieważ każda biblioteka może zostać załadowana z tego miejsca. Teoretycznie można wymienić nazwy bibliotek używanych przez wszystkie programy „wymagające większego zaufania” w systemie i upewnić się, że wszystkie te biblioteki znajdują się w „najbardziej zaufanych” katalogach, a wtedy „mniej zaufane” katalogi nie być używane, jeśli pojawiły się po bardziej zaufanych katalogach na ścieżce wyszukiwania, z wyjątkiem programów „wymagających mniejszego zaufania”. Ale byłoby to wyjątkowo kruche. Byłoby również całkiem bez sensu: jeśli atakujący może wstrzyknąć wartość LD_LIBRARY_PATHlub element /etc/ld.so.conf, na pewno mają bardziej bezpośrednią drogę do wykonywania dowolnego kodu, takie jak wstrzykiwanie wartość PATH, odLD_PRELOAD, itp. Zaufanie do ścieżki ładowania biblioteki ma znaczenie, gdy wykonanie przekracza granicę zaufania, tj. podczas uruchamiania programu z dodatkowymi uprawnieniami (np. program setuid / setgid lub via sudo). To, co dzieje się w tym przypadku, LD_LIBRARY_PATHjest puste.

Jeśli chodzi o /libvs /usr/lib, nie ma to większego znaczenia: są one dostarczane przez ten sam byt (system operacyjny) i nie powinno być biblioteki, która byłaby obecna w obu. Wymienienie jako /libpierwsze ma sens, ponieważ zapewnia (bardzo małą) przewagę wydajnościową: najczęściej używane biblioteki, zwłaszcza biblioteki używane przez małe podstawowe programy (dla których czas ładowania jest większy o ułamek całkowitego czasu działania niż duży, długi program do uruchamiania), znajdują się w /lib.