Módulos DLZ vinculados dinamicamente no BIND9

Módulos DLZ vinculados dinamicamente no BIND9

O BIND9 permite vincular módulos de zona carregável dinamicamente (DLZ) em tempo de execução usando o dlopendriver. O teste de unidade para essa funcionalidade é aprovado em meu ambiente, mas quando tento executar namedcom o arquivo de objeto compartilhado compilado vinculado, recebo este erro:

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

Já abri um ticket no BIND9 GitLabaqui, que inclui informações detalhadas sobre meu problema específico.

De maneira mais geral, estou me perguntando se as pessoas têm alguma ideia de problemas comuns ao tentar carregar objetos compartilhados ou têm experiência no uso de módulos DLZ. Meu palpite é que há algo que não estou entendendo sobre como eles funcionam e que há alguma configuração incorreta que está causando o problema. Claro, dicas de depuração também são apreciadas.


Página da Base de Conhecimento ISC "Usando DLZ no BIND":https://kb.isc.org/docs/aa-00995

Responder1

Então você está usando Debian ou Ubuntu, que habilitam o AppArmor por padrão e restringem quais locais o nameddaemon pode ler, gravar, mmap ou executar. Qualquer tentativa de carregar módulos de locais "errados" será negada pelo kernel e conectado dmesg.

A política padrão está em /etc/apparmor.d/usr.sbin.namede permite apenas dois locais:

  • /usr/lib/bind/*.so rm– para a maioria dos módulos empacotados
  • /{usr/,}lib/@{multiarch}/samba/bind9/*.so rm– para zonas Samba AD DC

Adições personalizadas podem ser feitas /etc/apparmor.d/local/usr.sbin.named(como indica a instrução #include na parte inferior do arquivo). Esse arquivo não possui delimitadores de início/fim, apenas as próprias regras adicionais, como:

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

Para recarregar o perfil após a edição, use:

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

informação relacionada