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

Question

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

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

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

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

Спасибо.

Answer 1

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

-Wl,-rpath,path/to/lib

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

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

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

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

Answer 2

ответ в первой цитируемой вами статье.

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

Answer 3

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

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

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

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

---

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

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

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

Answer 4

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

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 не нужно.