BIND9 le permite vincular módulos de zona cargable dinámicamente (DLZ) en tiempo de ejecución utilizando el dlopencontrolador. La prueba unitaria para esta funcionalidad pasa para mi entorno, pero cuando intento ejecutarla namedcon el archivo de objeto compartido compilado vinculado, aparece este error:
dlz_dlopen failed to open library '/usr/lib/dlz_example.so' - /usr/lib/dlz_example.so: failed to map segment from shared object
Ya abrí un ticket en el GitLab de BIND9aquí, que incluye información detallada sobre mi problema específico.
En términos más generales, me pregunto si la gente tiene alguna idea de los problemas comunes al intentar cargar objetos compartidos o si tiene experiencia en el uso de módulos DLZ. Mi corazonada es que hay algo que no entiendo acerca de cómo funcionan y hay una mala configuración tonta que está causando el problema. Por supuesto, también se agradecen los consejos de depuración.
Página de la base de conocimientos de ISC "Uso de DLZ en BIND":https://kb.isc.org/docs/aa-00995
Respuesta1
Entonces estás usando Debian o Ubuntu, que habilitan AppArmor de forma predeterminada y restringen nameddesde qué ubicaciones el demonio puede leer, escribir, mmap o ejecutar. El kernel rechazará cualquier intento de cargar módulos desde ubicaciones "incorrectas" y se iniciará sesión dmesg.
La política predeterminada está en /etc/apparmor.d/usr.sbin.namedy solo permite dos ubicaciones:
/usr/lib/bind/*.so rm– para la mayoría de los módulos empaquetados/{usr/,}lib/@{multiarch}/samba/bind9/*.so rm– para zonas Samba AD DC
Se pueden realizar adiciones personalizadas /etc/apparmor.d/local/usr.sbin.named(como indica la declaración #include en la parte inferior del archivo). Ese archivo no tiene delimitadores de inicio/fin, solo las reglas adicionales, como por ejemplo:
/usr/local/lib/*.so rm,
Para recargar el perfil después de editarlo, use:
apparmor_parser --replace /etc/apparmor.d/usr.sbin.named