BIND9 ermöglicht es Ihnen, dynamisch ladbare Zonenmodule (DLZ) zur Laufzeit mithilfe des dlopenTreibers zu verknüpfen. Der Unit-Test für diese Funktionalität ist in meiner Umgebung erfolgreich, aber wenn ich versuche, die Funktion namedmit der verknüpften kompilierten gemeinsam genutzten Objektdatei auszuführen, erhalte ich diesen Fehler:
dlz_dlopen failed to open library '/usr/lib/dlz_example.so' - /usr/lib/dlz_example.so: failed to map segment from shared object
Ich habe bereits ein Ticket im BIND9 GitLab eröffnetHier, das detaillierte Informationen zu meinem spezifischen Problem enthält.
Ganz allgemein frage ich mich, ob die Leute Einblick in häufige Probleme beim Laden gemeinsam genutzter Objekte haben oder Erfahrung mit der Verwendung von DLZ-Modulen haben. Ich vermute, dass ich etwas an ihrer Funktionsweise nicht verstehe und dass das Problem durch eine dumme Fehlkonfiguration verursacht wird. Natürlich sind auch Tipps zur Fehlerbehebung willkommen.
ISC Knowledge Base-Seite „Verwenden von DLZ in BIND“:https://kb.isc.org/docs/aa-00995
Antwort1
Sie verwenden also entweder Debian oder Ubuntu, die AppArmor standardmäßig aktivieren und einschränken, namedvon welchen Speicherorten der Daemon lesen, in welche er schreiben, mmap ausführen oder welche Speicherorte er verwenden darf. Alle Versuche, Module von den „falschen“ Speicherorten zu laden, werden vom Kernel abgelehnt und protokolliert dmesg.
Die Standardrichtlinie lautet /etc/apparmor.d/usr.sbin.namedund lässt nur zwei Standorte zu:
/usr/lib/bind/*.so rm– für die meisten verpackten Module/{usr/,}lib/@{multiarch}/samba/bind9/*.so rm– für Samba AD DC Zonen
Benutzerdefinierte Ergänzungen können vorgenommen werden /etc/apparmor.d/local/usr.sbin.named(wie die #include-Anweisung am Ende der Datei zeigt). Diese Datei hat keine Anfangs-/Ende-Trennzeichen, nur die zusätzlichen Regeln selbst, wie zum Beispiel:
/usr/local/lib/*.so rm,
Um das Profil nach der Bearbeitung neu zu laden, verwenden Sie:
apparmor_parser --replace /etc/apparmor.d/usr.sbin.named