Как мы можем защитить себя от других сторон, устанавливающих библиотеки DLL с такими же именами, как у некоторых из нас, в C: \ WINDOWS?

Question

Наш продукт включает в себя несколько DLL, встроенных из открытого исходного кода в файлы с именами по умолчанию, предоставленными разработчиками открытого исходного кода. Мы стараемся устанавливать файлы в наших собственных каталогах и тщательно управляем путем поиска (только для наших процессов), чтобы обеспечить удовлетворение загрузчика.

Другой разработчик - выдающийся интеллект - решил, что будет проще установить собственную сборку некоторых из того же открытого исходного кода в C: \ WINDOWS под теми же именами файлов DLL по умолчанию. Следовательно, когда мы запускаем процесс, который зависит от этих библиотек с открытым исходным кодом, система ищет C: \ WINDOWS перед нашими каталогами и находит библиотеки DLL, установленные другим разработчиком. И они, конечно, несовместимы.

Идеи, которые до сих пор приходили мне в голову:

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

По разным причинам ни один из этих вариантов на данный момент не приемлем.

Что еще мы можем сделать, чтобы защитить себя от высоких интеллектов мира?

Answer 1

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

Answer 2

Чтобы добавить и без того отличные ответы, у вас есть еще пара вариантов:

Предпочтительное решение этой проблемы, поддерживаемое начиная с Windows XP, заключается в том, чтобы превратить ваши dll в сборку win32 (они не обязательно должны быть .NET, но документация по созданию сборок win32 со строгими именами ужасно легка так что легко запутаться и подумать, что это только технология .NET).

Сборка отмечается более сложной, чем папка (с именем сборки), содержащая dll и .manifest (с именем сборки), который содержит элемент assemblyIdentiy, и количество файловых узлов для каждой dll в сборке.

Поиск на основе ассемблера работает даже тогда, когда библиотеки статически связаны!

• Самый простой вариант - создать неверсионные сборки и сохранить их в той же папке, что и ваши файлы .exe (при условии, что все ваши исполняемые файлы находятся в одной папке).

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

• Вы можете хранить свои сборки в частном альтернативном месте, если ожидаете, что ваше приложение будет использоваться в Windows 7 и выше. Создайте файл app.exe.config для каждого из ваших exe-файлов и укажите элемент probing privatePath в общей папке, где вы храните сборки.

• Если вы согласны с требованием административного доступа для выполнения установки (через MSI), тогда вы можете справиться с ужасно плохой документацией (ну, например, отсутствующей документацией), которая имеет дело с присвоением вашим сборкам строгого имени, а затем сохранить сборка в WinSxS.

Если вы не можете или не хотите связывать ваши dll как сборки, эта страница описывает порядок поиска dll

Использование таких функций, как SetDllDirectory поможет только для динамически загружаемых библиотек во время выполнения (через LoadLibrary).

Dll порядок поиска используется быть:

1. Каталог, содержащий процесс exe
2. Текущий каталог
3. различные папки Windows
4. PATH

Что вы могли бы использовать в своих интересах - запускайте каждый exe, устанавливая «текущий» каталог в папку, содержащую библиотеки OSS.

С появлением SafeDllSearchMode порядок поиска теперь:

1. Каталог, содержащий процесс exe
2. различные папки Windows
3. Текущий каталог
4. PATH

Это означает, что теперь у вас меньше контроля, чем когда-либо :( - Он работает еще быстрее для "ненадежных" папок c: \ windows & System32.

Опять же, если исходная dll загружается через LoadLibrary, и ее зависимые dll являются проблемой, то LoadLibraryEx с флагом LOAD_WITH_ALTERED_SEARCH_PATH вызовет следующий порядок поиска (при условии, что вы передали полный путь к LoadLibraryEx): -

1. Часть каталога пути Dll, переданная в LoadLibraryEx
2. различные папки Windows
3. Текущий каталог
4. PATH

Answer 3

Каталог, из которого загружено приложение, обычно является первым каталогом, в котором выполняется поиск при загрузке DLL. Однако вы можете использовать SetDllDirectory, чтобы получить «альтернативный порядок поиска». В этом случае каталог, который вы указали для SetDllDirectory, будет сначала найден.

Существует также SafeDllSearchMode, который влияет на это в определенной степени. Включение его исключает текущий каталог из поиска.

Answer 4

Может, просто скомпилировать их в статическую библиотеку?

Почему бы и нет?

Кроме того, текущий каталог, из которого активирован exe, ищется до c: \ windows.