В каком порядке динамический компоновщик Linux ищет пути?

Это не дубликат, потому что имеет дело с особенностью, которую я заметил, когда использую /etc/ld.so.conf.

Чтобы получить пути, по которым динамический компоновщик ищет библиотеки, я запускаю команду ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g". Когда /etc/ld.so.confнет путей, перечисленных в нем. Вывод предыдущей команды

/lib
/usr/lib

Я понял, что он ищет /libсначала, а потом /usr/lib. Когда я добавляю новый путь, такой как /usr/local/lib, /etc/ld.so.confи затем переделываю /etc/ld.so.cache, вывод из ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"становится

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

Я нахожу это странным, потому что, если я прав, что порядок поиска в перечисленных каталогах сверху вниз, то дополнительные каталоги ищутся до /libи /usr/lib. То, что дополнительные каталоги ищутся до доверенных каталогов, само по себе не странно, но когда /libпоиск выполняется до /usr/libэтого, это странно, потому что /bin& /sbinищутся после /usr/bin& /usr/sbinin PATH.

Даже если пути, перечисленные в списке, ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"ищутся снизу вверх, это все равно будет искаженный порядок, потому что дополнительные каталоги будут искать после доверенных, а /libпотом искать /usr/lib.

Итак, каков порядок ld.soпоиска путей для библиотек? Почему /libищется раньше /usr/lib? Если это не так, то зачем искать дополнительные каталоги /lib?

Порядок документирован в руководстве динамического компоновщика, которое есть ld.so. Это:

1. каталоги от LD_LIBRARY_PATH;
2. каталоги от /etc/ld.so.conf;
3. /lib;
4. /usr/lib,

(Я немного упрощаю, подробности смотрите в руководстве.)

Порядок имеет смысл, если учесть, что это единственный способ переопределить библиотеку в расположении по умолчанию с помощью пользовательской библиотеки. LD_LIBRARY_PATHэто пользовательская настройка, она должна быть выше других. /etc/ld.so.confэто локальная настройка, она предшествует операционной системе по умолчанию. Поэтому, как пользователь, если я хочу запустить программу с другой версией библиотеки, я могу запустить программу с LD_LIBRARY_PATHуказанием местоположения этой другой версии библиотеки. И как администратор, я могу поставить другую версию библиотеки в /usr/local/libи список /usr/local/libв /etc/ld.so.conf.

Доверие не входит в это. Любой каталог, указанный в этом пути поиска, должен быть доверенным, поскольку любая библиотека может быть загружена оттуда. Теоретически, вы могли бы перечислить имена библиотек, используемые всеми программами, «требующими большего доверия» в вашей системе, и убедиться, что все эти библиотеки присутствуют в «наиболее надежных» каталогах, и тогда «менее доверенные» каталоги не будут быть использованы, если они пришли после более надежных каталогов в пути поиска, за исключением программ, «требующих меньшего доверия». Но это было бы чрезвычайно хрупким. Это также было бы довольно бессмысленно: если злоумышленник может внедрить значение LD_LIBRARY_PATHили элемент /etc/ld.so.conf, он, несомненно, имеет более прямой путь к выполнению произвольного кода, такого как введение значения PATH, изLD_PRELOADи т. д. Доверие к пути загрузки библиотеки имеет значение, когда выполнение пересекает границу доверия, т. е. при запуске программы с дополнительными привилегиями (например, setuid / setgid program или via sudo). То, что происходит в этом случае, это то, что LD_LIBRARY_PATHскрыто.

Что касается /libvs /usr/lib, это не имеет большого значения: они предоставляются одной и той же сущностью (операционной системой), и не должно быть библиотеки, которая присутствует в обеих. Имеет смысл /libсначала перечислить, потому что это обеспечивает (очень крошечное) преимущество в производительности: наиболее часто используемые библиотеки, особенно библиотеки, используемые небольшими базовыми программами (для которых время загрузки составляет большую долю общего времени выполнения, чем большое, длинное). -running программа), расположены в /lib.