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-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
