Гуру говорят, что LD_LIBRARY_PATH плох - какая альтернатива?

Ответ 1

Вы можете попробовать:

-Wl,-rpath,path/to/lib

к параметрам компоновщика. Это избавит вас от необходимости беспокоиться о переменной среды LD_LIBRARY_PATH, и вы можете решить в время компиляции указать на определенную библиотеку.

Для пути относительно двоичного файла вы можете использовать $ORIGIN, например

-Wl,-rpath,'$ORIGIN/../lib'

($ ORIGIN может не работать при статической привязке к общим библиотекам с помощью ld, используйте -Wl, - allow-shlib- undefined, чтобы исправить это)

Ответ 2

Я всегда устанавливал LD_LIBRARY_PATH, и у меня никогда не было проблемы.

Чтобы процитировать первую ссылку:

Когда мне нужно установить LD_LIBRARY_PATH? Короткий ответ никогда. Зачем? Некоторые пользователи, похоже, задают эту переменную среды из-за плохой рекомендации других пользователей или плохо связанного кода, что они не знают, как исправить.

Это НЕ то, что я называю окончательной постановкой задачи. На самом деле это напоминает Мне это не нравится. [YouTube, но SFW].

Эта вторая запись в блоге (http://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the) гораздо более приближена к характеру проблемы... которая, кажется, в двух словах, конфликты версий библиотеки ThisProgram требует Foo1.2, но для этой программы требуется Foo1.3, поэтому вы не можете запускать обе программы (легко). Обратите внимание, что большинство из этих проблем сбрасываются простой оболочкой script, которая устанавливает LD_LIBRARY_PATH только для исполняющей оболочки, которая (почти всегда) представляет собой отдельный дочерний процесс интерактивной оболочки.

Заметим также, что альтернативы довольно хорошо объяснены в сообщении.

Я просто смущен тем, почему вы отправляете вопрос, содержащий ссылки на статьи, которые, очевидно, отвечают на ваш вопрос... У вас есть конкретный вопрос, который не был рассмотрен (достаточно ясно) в любой из этих статей?

Ответ 3

ответ в первой статье, которую вы цитировали.

В UNIX расположение библиотеки может быть задано параметром -L dir для компилятора..... В качестве альтернативы использованию опций -L и -R вы можете установить переменную среды LD_RUN_PATH перед компиляцией кода.

Ответ 4

Я нахожу, что существующие ответы действительно отвечают на вопрос простым способом:

• LD_RUN_PATH используется компоновщиком (см. ld) во время соединения вашего программного обеспечения. Он используется, только если в командной строке нет -rpath ... (-Wl,rpath ... в командной строке gcc). Пути (ы), определенные в этой переменной, добавляются в запись RPATH в вашем двоичном файле ELF. (Вы можете увидеть, что RPATH использует objdump -x binary-filename - в большинстве случаев он не существует, хотя он присутствует в моих двоичных файлах разработки, но после установки окончательной версии RPATH удаляется.)

• LD_LIBRARY_PATH используется во время выполнения, когда вы хотите указать каталог, в котором динамический компоновщик (см. ldd) должен искать библиотеки. Указание неправильного пути может привести к загрузке неправильных библиотек. Это используется в дополнение к значению RPATH, определенному в вашем двоичном файле (как в 1.)

LD_RUN_PATH действительно не создает угрозы безопасности, если вы не программист и не знаете, как его использовать. Поскольку я использую CMake для создания моего программного обеспечения, -rpath используется все время. Таким образом, мне не нужно устанавливать все для запуска моего программного обеспечения. ldd может автоматически найти все .so файлы. (Предположительно, это также должно было сделать автомодельное окружение, но это было не очень хорошо для сравнения.)

LD_LIBRARY_PATH - это переменная времени выполнения, поэтому вы должны быть осторожны с ней. При этом многие общие объекты будут действительно трудно справиться, если у нас не будет этой особой функции. Является ли это угрозой безопасности, возможно, нет. Если хакер захватывает ваш компьютер, в этом хакере все равно доступен LD_LIBRARY_PATH. Что может случиться, так это то, что вы используете неправильный путь в этой переменной, ваш двоичный файл может не загружаться, но если он загружается, может закончиться сбойный двоичный файл или, по крайней мере, двоичный код, который не работает совершенно правильно. Одна из проблем заключается в том, что со временем вы получаете новые версии библиотеки, и вы, вероятно, забудете удалить LD_LIBRARY_PATH, что означает, что вы можете использовать небезопасную версию библиотеки.

Еще одна возможность для безопасности заключается в том, что хакер устанавливает поддельную библиотеку с тем же именем, что и бинарный поиск, библиотеку, которая включает в себя все те же функции, но некоторые из этих функций заменены скрытым кодом. Он может загрузить эту библиотеку, изменив переменную LD_LIBRARY_PATH. Тогда это в конечном итоге будет выполнено хакером. Опять же, если хакер может добавить такую ​​библиотеку в вашу систему, он уже и, вероятно, не должен делать что-либо подобное в первую очередь (поскольку он в любом случае имеет полный контроль над вашей системой.) В действительности, если хакер может разместить только библиотеку в своем аккаунте, он ничего не сделает (если ваш блок Unix не безопасен в целом...) Если хакер может заменить одну из ваших библиотек /usr/lib/..., он уже имеет полный доступ к вашей система. Поэтому LD_LIBRARY_PATH не требуется.