Linux, общая библиотека использует функции из основной программы вместо других общих библиотек

Я создаю общую библиотеку, которая загружается из приложения (которое я не могу контролировать). Моя библиотека использует другие общие библиотеки, которые, в свою очередь, используют другие общие библиотеки, сложные, но не необычные.

Проблема заключается в том, что основное приложение имеет функции, присутствующие в одной из библиотек, расположенных ниже по цепочке, а точнее, это openLDAP, который в свою очередь использует функции openSSL: 
Main app->My library->openLDAP libraries->openSSL libraries

Я предполагаю, что основное приложение реализует openSSL либо с помощью статическая компоновка или простое копирование / вставка исходного кода.

Мой вопрос: Могу ли я контролировать, какие функции openLDAP использует моя библиотека, или мне нужно перекомпилировать openLDAP со статической связью с openSSL?

Поскольку openSSL обновляется довольно часто из-за проблем безопасности, я не хочу статическую копию этого, если мне не нужно. И зачем повторно распространять проприетарную копию openLDAP, когда она является частью большинства пакетов дистрибутивов...

3 4
linux shared-libraries

3 ответа:

Прямо сейчас у вас есть исполняемый файл, переопределяющий то, что в противном случае было бы системным выбором библиотеки OpenSSL по умолчанию. Это в пределах прав исполняемого файла, чтобы сделать это, и вы действительно не можете остановить его.

Статическое связывание OpenSSL в вашей библиотеке также может не быть решением. Во-первых, что делать, если исполняемый файл действительно использует другую версию? Во-вторых, что делать, если OpenSSL имеет некоторые глобальные переменные? Теперь у вас в библиотеке будет два экземпляра тот же процесс, который не является хорошей идеей и может вызвать ошибки.

На мой взгляд, лучший ответ, который мы имеем в Linux, - это не считать такого рода вещи проблемой. Если исполняемый файл загружает плохую версию OpenSSL, это не ошибка вашей библиотеки. Самое большее, вы можете проверить, какая версия загружена, и отказаться от запуска, если по какой-то причине она несовместима с вашей библиотекой.

3

Я предполагаю, что основное приложение реализует openSSL либо путем статической компоновки или простого копирования / вставки исходного кода.

Это неправильные вещи. Если разработчик приложения стреляет по ноге, то вы ничего не можете сделать.

Разработчик приложения должен видеть, что ваша библиотека зависит от библиотеки OpenSSL (используя команду ldd), тогда он не должен связывать OpenSSL again as staticly or copy paste its code.

Если некоторые функции из OpenSSL не создают никакого беспорядка и если их можно использовать просто как и любой статический метод любого класса java, только разработчик приложения должен взять на себя риск реализации этого кода в приложении.

0

Решение состояло в использовании RTLD_DEEPBIND в dlopen (3):

RTLD_DEEPBIND (начиная с glibc 2.3.4)

Поместите область поиска символов в этой библиотеке перед глобальная область. Это означает, что автономная библиотека будет использовать свои собственные символы в предпочтении к глобальным символам с тем же именем содержится в библиотеках, которые уже загружены. Этого флага нет указывается в POSIX.1-2001.

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

0