Bug#584911: bind9: hard-coded dependency on "/usr/lib/ssl/openssl.cnf" might cause trouble

[Gebauer, Mirko (FRA-MRM)]

Package: bind9
Version: 1:9.6.ESV.R1+dfsg-0+lenny1
Severity: serious

(This also seems to affect newer versions of bind9; also tested with 1:9.7.0.dfsg.P1-1~bpo50+1 from backports.)

I had to invest quite some time today in figuring out why the recent security update for bind9 worked fine on all our systems running lenny, but failed on the primary DNS server. Unfortunately, the syslog output gives no clue as to why bind9 fails to start:

07-Jun-2010 15:06:22.132 starting BIND 9.6-ESV-R1 -c /etc/bind/named.conf -g -u bind
07-Jun-2010 15:06:22.132 built with '--prefix=/usr' '--build=x86_64-linux-gnu' '--host=x86_64-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var/run/bind' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-dlz-postgres=no' '--with-dlz-mysql=no' '--with-dlz-bdb=yes' '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=yes' '--enable-ipv6' 'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' 'LDFLAGS=' 'CPPFLAGS=' 'CXXFLAGS=-g -O2' 'FFLAGS=-g -O2'
07-Jun-2010 15:06:22.132 adjusted limit on open files from 1024 to 1048576
07-Jun-2010 15:06:22.132 found 4 CPUs, using 4 worker threads
07-Jun-2010 15:06:22.132 using up to 4096 sockets

Running bind9 manually nets the missing information:

# named -c /etc/bind/named.conf -g -u bind
07-Jun-2010 15:06:22.132 starting BIND 9.6-ESV-R1 -c /etc/bind/named.conf -g -u bind
07-Jun-2010 15:06:22.132 built with '--prefix=/usr' '--build=x86_64-linux-gnu' '--host=x86_64-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var/run/bind' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-dlz-postgres=no' '--with-dlz-mysql=no' '--with-dlz-bdb=yes' '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=yes' '--enable-ipv6' 'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' 'LDFLAGS=' 'CPPFLAGS=' 'CXXFLAGS=-g -O2' 'FFLAGS=-g -O2'
07-Jun-2010 15:06:22.132 adjusted limit on open files from 1024 to 1048576
07-Jun-2010 15:06:22.132 found 4 CPUs, using 4 worker threads
07-Jun-2010 15:06:22.132 using up to 4096 sockets
Auto configuration failed
140502524483328:error:0200100D:system library:fopen:Permission denied:bss_file.c:122:fopen('/usr/lib/ssl/openssl.cnf','rb')
140502524483328:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:127:
140502524483328:error:0E078002:configuration file routines:DEF_LOAD:system lib:conf_def.c:199:

"/usr/lib/ssl/openssl.cnf" is a symlink to "/etc/ssl/openssl.cnf", both provided by the package "openssl". Unfortunately, on the respective machine, "/etc/ssl/openssl.cnf" is modified and not world-readable as it is by default after installing the "openssl" package.

If "openssl" is not installed and therefore "/usr/lib/ssl/openssl.cnf" does not exist (like on our secondary DNS server), everything is fine. But if the file, or symlink in this case, does exist, but (its target) is not readable for the user the named process runs as, then *bang*.

I think the point is, bind9 should not expect to be able to read configuration files from other packages that it not depends on. Also, if a dependency on "openssl" is explicit and intentional, then users should be warned if some configuration files need to be readable by the user the named process runs as. I clearly was not expecting that there is a connection between "bind9" and "openssl" whatsoever.

Best regards,
Mirko Gebauer

</pre> This message contains information which may be confidential and privileged.Unless you <br>
are the intended recipient (or authorized to receive this message for the intended <br>
recipient), you may not use, copy, disseminate or disclose to anyone the message or <br>
any information contained in the message. If you have received the message in error, <br>
please advise the sender by reply e-mail, and delete the message. <br>
Thank you very much. <br>
(A) <pre>

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Gebauer, Mirko (FRA-MRM)]

> BIND uses the NULL argument, as far as I can tell. So this might be
> an OpenSSL bug.

Well, all I can say is that bind9 as provided by the package version "1:9.5.1.dfsg.P3-1+lenny1" doesn't show the reported behavior, and that both "1:9.5.1.dfsg.P3-1+lenny1" and the current "1:9.6.ESV.R1+dfsg-0+lenny1" depend on the same version of "libssl0.9.8".

Since I'm not really an expert in building Debian packages, I'll leave the conclusion to people that have more knowledge on the subject than me :-)

Best regards,
Mirko Gebauer

P.S.: This also effects "bind9-host" (version "1:9.6.ESV.R1+dfsg-0+lenny1"); if a user that invokes the "host" command provided via "bind9-host" lacks the permission to read the target of "/usr/lib/ssl/openssl.cnf", he gets the same nice error feedback.