Hallo Tilmann und Alexander,
eigentlich läuft alles ganz gut, (die DNSauflöung funktioniert in beide Richtungen) aber vielleicht kann mir doch einer verraten, um welches directory es sich hier handelt:
named: the working directory is not writable
Ist doch gut, wenn der named da nicht reinschreiben kann. Das soll er ja auch nicht.
Also ein Programmierfehler?
########################################################################## nebenbei:
less /etc/init.d/named ... ROOTDIR_MOUNT='/etc/named /etc/pki/dnssec-keys /var/named /etc/named.conf /etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf /etc/rndc.key /usr/lib64/bind /usr/lib/bind /etc/named.iscdlv.key' ...
Wozu ist der Eintrag: /usr/lib64/bind /usr/lib/bind, wenn die Verz. leer sind. Historie? Evtl. ist mein Horizont zu tief um den Nutzen der Verz. zuerkennen. #########################################################################
outsch! Das (chown -R named ...) will man definitiv nicht. Blöde Idee, wenn Du mal drüber nachdenkst.
# grep named /etc/passwd named:x:25:25:Named:/var/named:/sbin/nologin
1. Single-Server 2. DNS-Zonetransfer ist nicht zu gelassen. 3. query nur an Port 53 UDP 192.168.1.x/26 und 127.0.0.1 möglich 4. SeLinux aktiviert 5. IPv6 disabled
Derzeit sehe ich keine Gefahr, aber evtl. kannst Du mir das erklären?
Eine Gefahr ist z.B.: # setfacl -R -m u:nobody:rwx / :-) da würden sich die Hacker freuen und # service iptables stop # service ip6tables stop u.s.w.
Dann kannst Du auch dem Apache Schreibrechte auf allen Inhalt im DocumentRoot geben :(
Guter Witz, denn dort liegen u.U. auch php-dateien...
Stör Dich einfach nicht an der Logmeldung, ist nur eine "Warnung" und sollte schlicht ignoriert werden.
Werde ich machen.
Danke an alle Wolfgang
Hallo Wolfgang,
Am 31.10.2011 16:43, schrieb Wolfgang:
Hallo Tilmann und Alexander,
Ein 'n' reicht, danke.
named: the working directory is not writable
Ist doch gut, wenn der named da nicht reinschreiben kann. Das soll er ja auch nicht.
Also ein Programmierfehler?
Nein, warum? BIND informiert Dich darüber, dass er in sein Arbeitsverzeichnis nicht schreiben kann. Das kann für manche Administratoren von Belang sein, und wenn nur als Bestätigung, dass der Sicherheit an dieser Stelle genüge getan ist. Also ist es durchaus legitim, das ins Log zu schreiben. Allenfalls könnte man es als Dokumentationsmangel betrachten, wenn es für manche Anwender zu schwer zu erkennen ist, dass hier kein Handlungsbedarf besteht.
########################################################################## nebenbei:
less /etc/init.d/named ... ROOTDIR_MOUNT='/etc/named /etc/pki/dnssec-keys /var/named /etc/named.conf /etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf /etc/rndc.key /usr/lib64/bind /usr/lib/bind /etc/named.iscdlv.key' ...
Wozu ist der Eintrag: /usr/lib64/bind /usr/lib/bind, wenn die Verz. leer sind. Historie?
Keine Ahnung. Vielleicht sind sie nicht auf jedem System leer. So isoliert eine einzelne Zeile aus einem Skript zu kritisieren ist relativ problematisch. Schau halt mal nach, wozu die Variable ROOTDIR_MOUNT benutzt wird, vielleicht erschließt sich dann auch, warum diese Einträge unter Umständen notwendig sein könnten. Notfalls mach den Autor des Skripts ausfindig und frag ihn.
outsch! Das (chown -R named ...) will man definitiv nicht. Blöde Idee, wenn Du mal drüber nachdenkst.
# grep named /etc/passwd named:x:25:25:Named:/var/named:/sbin/nologin
- Single-Server
- DNS-Zonetransfer ist nicht zu gelassen.
- query nur an Port 53 UDP 192.168.1.x/26 und 127.0.0.1 möglich
- SeLinux aktiviert
- IPv6 disabled
Derzeit sehe ich keine Gefahr, aber evtl. kannst Du mir das erklären?
Zweite Verteidigungslinie gegen eventuelle Bugs in BIND. Es soll schon vorgekommen sein, dass selbst so renommierte Programme wie BIND einen Pufferüberlauf-Bug haben, über den man Schadcode zur Ausführung bringen kann - z.B. auch per manipuliertem reply. Der liefe dann unter UID named. Daran ändert auch nichts, dass der User auf "nologin" steht. Deshalb sollte diese UID prophylaktisch so wenige Rechte wie möglich haben.
HTH Tilman