Bug 223842 - dns/bind912: fails to start, stating possibly wrong reason for this
Summary: dns/bind912: fails to start, stating possibly wrong reason for this
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Mathieu Arnold
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-24 14:04 UTC by emz
Modified: 2018-07-16 17:55 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (mat)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description emz 2017-11-24 14:04:17 UTC
dns/bind912 from recent ports.

Fails to start:

Nov 24 15:49:53 g1fw1 named[26422]: starting BIND 9.12.0b2 <id:5b1e929>
Nov 24 15:49:53 g1fw1 named[26422]: running on FreeBSD amd64 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC 2017     root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
Nov 24 15:49:53 g1fw1 named[26422]: built with '--localstatedir=/var' '--disable-linux-caps' '--disable-symtable' '--with-randomdev=/dev/random' '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlopen=yes' '--sysconfdir=/usr/local/etc/namedb' '--disable-dnstap' '--disable-filter-aaaa' '--disable-fixed-rrset' '--without-geoip' '--with-idn=/usr/local' '--enable-ipv6' '--with-libjson' '--disable-largefile' '--with-lmdb' '--with-python=/usr/local/bin/python2.7' '--disable-querytrace' '--enable-rpz-nsdname' '--enable-rpz-nsip' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-threads' '--without-gssapi' '--with-openssl=/usr' '--disable-native-pkcs11' '--with-dlz-filesystem=yes' '--without-gost' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd11.1' 'build_alias=amd64-portbld-freebsd11.1' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector -isystem /usr/local/include -fno-strict-aliasing' 'LDFLAGS= -fstack-protector' 'LIBS=-L/usr/l
Nov 24 15:49:53 g1fw1 named[26422]: running as: named -t /var/named -u bind -c /usr/local/etc/namedb/named.conf
Nov 24 15:49:53 g1fw1 named[26422]: ----------------------------------------------------
Nov 24 15:49:53 g1fw1 named[26422]: BIND 9 is maintained by Internet Systems Consortium,
Nov 24 15:49:53 g1fw1 named[26422]: Inc. (ISC), a non-profit 501(c)(3) public-benefit 
Nov 24 15:49:53 g1fw1 named[26422]: corporation.  Support and training for BIND 9 are 
Nov 24 15:49:53 g1fw1 named[26422]: available at https://www.isc.org/support
Nov 24 15:49:53 g1fw1 named[26422]: ----------------------------------------------------
Nov 24 15:49:53 g1fw1 named[26422]: found 8 CPUs, using 8 worker threads
Nov 24 15:49:53 g1fw1 named[26422]: using 7 UDP listeners per interface
Nov 24 15:49:53 g1fw1 named[26422]: using up to 4096 sockets
Nov 24 15:49:53 g1fw1 named[26422]: loading configuration from '/usr/local/etc/namedb/named.conf'
Nov 24 15:49:53 g1fw1 named[26422]: reading built-in trusted keys from file '/usr/local/etc/namedb/bind.keys'
Nov 24 15:49:53 g1fw1 named[26422]: using default UDP/IPv4 port range: [49152, 65535]
Nov 24 15:49:53 g1fw1 named[26422]: using default UDP/IPv6 port range: [49152, 65535]
Nov 24 15:49:53 g1fw1 named[26422]: listening on IPv4 interface ix0, 10.0.4.2#53
Nov 24 15:49:53 g1fw1 named[26422]: listening on IPv4 interface ix0, 10.0.4.1#53
Nov 24 15:49:53 g1fw1 named[26422]: listening on IPv4 interface ix1, 92.223.102.252#53
Nov 24 15:49:53 g1fw1 named[26422]: listening on IPv4 interface ix1, 92.223.102.251#53
Nov 24 15:49:53 g1fw1 named[26422]: listening on IPv6 interface lo0, ::1#53
Nov 24 15:49:53 g1fw1 named[26422]: listening on IPv6 interface lo0, fe80::1%5#53
Nov 24 15:49:53 g1fw1 named[26422]: listening on IPv4 interface lo0, 127.0.0.1#53
Nov 24 15:49:53 g1fw1 named[26422]: listening on IPv4 interface gre0, 172.16.0.7#53
Nov 24 15:49:53 g1fw1 named[26422]: generating session key for dynamic DNS
Nov 24 15:49:53 g1fw1 named[26422]: sizing zone task pool based on 6 zones
Nov 24 15:49:53 g1fw1 named[26422]: none:102: 'max-cache-size 90%' - setting to 14553MB (out of 16170MB)
Nov 24 15:49:53 g1fw1 named[26422]: set up managed keys zone for view internal, file 'internal.mkeys'
Nov 24 15:49:53 g1fw1 named[26422]: none:102: 'max-cache-size 90%' - setting to 14553MB (out of 16170MB)
Nov 24 15:49:53 g1fw1 named[26422]: set up managed keys zone for view external, file 'external.mkeys'
Nov 24 15:49:53 g1fw1 named[26422]: none:102: 'max-cache-size 90%' - setting to 14553MB (out of 16170MB)
Nov 24 15:49:53 g1fw1 named[26422]: command channel listening on 127.0.0.1#953
Nov 24 15:49:53 g1fw1 named[26422]: the working directory is not writable
Nov 24 15:49:53 g1fw1 named[26422]: loading configuration: permission denied
Nov 24 15:49:53 g1fw1 named[26422]: exiting (due to fatal error)
===Cut===

Yup, I know what it looks like. It looks like it cannot load the named.conf or zones. But the fact is he can - ktrace shows it loads the named.conf (furthermore, when it cannot load named.conf it gives explicit error about inability to load named.conf), but not the zones. Sources search doesn't give the reason, I even failed to locate the source file saying "loading configuration:" (only "loading configuration from '%s" and "reloading configuration"), and I've tested named.conf opening under bind user temporarily given a login shell - it's clear that he can read this file.

Furthermore running bind912 without the chroot and under the root user also doesn't resolve this, thus so far I failed to determine the reason, so I'm sending this PR.

Also a minor bug: dns/bind911 also requires /var/named directory, and it's not created automatically inside a chroot. In this case it complains about: 

error writing NTA file for view %VIEVNAME: permission denied

Btw I've tested whether this is the reason of a fatal error - nope, creating /var/named inside a chroot doesn't resolve this.

Workaround: use dns/bind911 or dns/bin910 or dns/bind99, - all of them work just fine on the same set of configuration files.
Comment 1 Mathieu Arnold freebsd_committer 2018-01-09 12:13:31 UTC
After much fiddling, I was able to reproduce the problem you are encountering.

You changed the "directory" directive to something like /usr/local/etc/namedb.  With that change, named now refuses to start because it cannot write to this directory.  To fix this, either set "directory" back to its stock value, or edit /usr/local/etc/mtree/BIND.chroot.local.dist to change the owner of the "namedb" directory to bind instead of root.  Not that this is not a good idea because then named can write to all its configuration, and in case of a security hole, a malicious user could edit the configuration files.
Comment 2 ping mai 2018-02-07 01:30:38 UTC
(In reply to Mathieu Arnold from comment #1)
I have the exact same problem with bind912.

same set of config files works fine with bind911.

same config files works without chroot in bind912.

my "directory" directive is set to /usr/local/etc/namedb.  without it bind
cannot find rest of the config files and fails checkconf.
Comment 3 Mathieu Arnold freebsd_committer 2018-02-07 13:18:02 UTC
The fix is the same for bind912.
Comment 4 ping mai 2018-02-08 07:33:19 UTC
what exactly is the fix?
Comment 5 Mathieu Arnold freebsd_committer 2018-02-08 11:25:27 UTC
From the comment that closed the PR:

> edit /usr/local/etc/mtree/BIND.chroot.local.dist to change the
> owner of the "namedb" directory to bind instead of root.
Comment 6 ping mai 2018-04-19 09:05:21 UTC
does this have to be broken by default?
without the "directory" directive it looks for everything in "/var/named/*"
Comment 7 Mathieu Arnold freebsd_committer 2018-04-20 12:27:25 UTC
The BIND9 ports are secure by default, it means BIND9 cannot write to the directory where its configuration is stored.  If, for some reason, you want to lessen this security, you absolutely can, you can change the directory directive, and you can change the mtree file that ensures permissions are correct.
Comment 8 ping mai 2018-04-21 01:41:14 UTC
I understand and agree with your points about security.  My point was, I do not want to change mtree every time I install the port.  I am running bind in chroot.  bind912, your port, is looking for write permission in the "directory".
Previous ports did not.  How do you suggest we fix this?
Comment 9 ping mai 2018-04-21 01:53:29 UTC
let me ask the question another way, for those of us running chroot, how would you change named configuration so that the bind912 port works out of the box?
Comment 10 emz 2018-04-21 07:07:07 UTC
and I totally agree with ping mai, port clearly conflicts with base system. Who runs named without chroot nowadays anyway ?
Comment 11 Mathieu Arnold freebsd_committer 2018-04-22 10:11:50 UTC
(In reply to ping mai from comment #8)
> I understand and agree with your points about security.  My point was, I do
> not want to change mtree every time I install the port.  I am running bind
> in chroot.  bind912, your port, is looking for write permission in the
> "directory".
> Previous ports did not.  How do you suggest we fix this?

During the BIND9 9.12 development cycle, named started requiring that its working "directory" was writable, in https://gitlab.isc.org/isc-projects/bind9/commit/16d6fab2e59f1fdf63eb71fc59e138031f5c5005 and https://gitlab.isc.org/isc-projects/bind9/commit/1ca7e01aa741f2238690d7d9e247293187af79c8.

The port then made sure that the directory was writable, and other directories where not.
The port also allowed the user who wanted to change "directory", from an empty directory where a security issue could not do much harm, to its parent directory to change the mtree file to lessen the security.



(In reply to ping mai from comment #9)
> let me ask the question another way, for those of us running chroot, how
> would you change named configuration so that the bind912 port works out of
> the box?

As bind912 works out of the box, I am unsure what you mean.  If you mean "out of the box with the directory directive changed" then you only need to follow the steps in comment #1, like I already told you.


(In reply to emz from comment #10)
> and I totally agree with ping mai, port clearly conflicts with base system.
> Who runs named without chroot nowadays anyway ?

I do not understand, BIND9 has not been in the base system for years, how can it conflict.
Comment 12 ping mai 2018-04-24 22:14:41 UTC
(In reply to Mathieu Arnold from comment #11)

are you saying the only way to get bind912 port to work is to change the mtree definition?  do we agree that that is what we want to avoid?

let's say you are running named chroot.  and you wish to reference /usr/local/etc/namedb/named.root which is included in your port.  how would you do that in your named.conf?
Comment 13 Mathieu Arnold freebsd_committer 2018-04-27 09:30:39 UTC
I am saying that if you change "directory" then you must relax the permissions in the mtree file.  It may be what *you* agreed with yourself that it is what you wanted to avoid, but it is the *correct* way to do it.  It is also the only reason the mtree files are installed with @sample so that they are not overwritten on upgrades.

If you keep "directory" to the default value, to references files outside of it, you put the full path to the file, have a look at how named.conf.sample does it.