Динамически подключаемые модули DLZ в BIND9

Динамически подключаемые модули DLZ в BIND9

BIND9 позволяет вам связывать динамически загружаемые модули зоны (DLZ) во время выполнения с помощью драйвера dlopen. Модульный тест для этой функциональности проходит для моей среды, но когда я пытаюсь запустить его namedсо связанным скомпилированным файлом общего объекта, я получаю эту ошибку:

dlz_dlopen failed to open library '/usr/lib/dlz_example.so' - /usr/lib/dlz_example.so: failed to map segment from shared object

Я уже открыл тикет в BIND9 GitLabздесь, который включает в себя подробную информацию о моей конкретной проблеме.

В целом, мне интересно, есть ли у людей понимание распространенных проблем при попытке загрузки общих объектов или опыт использования модулей DLZ. Я подозреваю, что я чего-то не понимаю в том, как они работают, и есть какая-то глупая неправильная конфигурация, которая вызывает проблему. Конечно, советы по отладке также приветствуются.


Страница базы знаний ISC «Использование DLZ в BIND»:https://kb.isc.org/docs/aa-00995

решение1

Итак, вы используете Debian или Ubuntu, которые по умолчанию включают AppArmor и ограничивают, namedиз каких мест демон может читать, писать, или mmap, или выполнять. Любые попытки загрузить модули из "неправильных" мест будут отклонены ядром и зарегистрированы dmesg.

Политика по умолчанию допускает /etc/apparmor.d/usr.sbin.namedтолько два местоположения:

  • /usr/lib/bind/*.so rm– для большинства упакованных модулей
  • /{usr/,}lib/@{multiarch}/samba/bind9/*.so rm– для зон Samba AD DC

Пользовательские дополнения могут быть сделаны /etc/apparmor.d/local/usr.sbin.named(как показывает оператор #include в конце файла). Этот файл не имеет никаких начальных/конечных разделителей, только сами дополнительные правила, такие как:

/usr/local/lib/*.so rm,

Чтобы перезагрузить профиль после редактирования, используйте:

apparmor_parser --replace /etc/apparmor.d/usr.sbin.named

Связанный контент