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

Я прочитал несколько статей о проблемах с использованием LD_LIBRARY_PATH, даже в составе сценария оболочки:

http://linuxmafia.com/faq/Admin/ld-lib-path.html

http://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the

В этом случае - каковы рекомендуемые альтернативы?

Благодарю.

Источник

4 ответа

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

-Wl,-rpath,path/to/lib

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

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

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

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

Источник

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

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

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

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

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

Обратите внимание, что альтернативы довольно хорошо объяснены в посте.

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

Источник

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

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

Источник

Я считаю, что существующие ответы на самом деле отвечают на вопрос прямо:

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

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

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

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

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

Источник
Другие вопросы по тегам