Bug#584911: bind9: hard-coded dependency on /usr/lib/ssl/openssl.cnf might cause trouble
Thanks Florian, for your prompt responses. And please excuse the ugly e-mail style without proper line wrappings that Outlook (company...) causes in Debian's BTS. I'm still curious why the bug we've stumbled upon in OpenSSL was no issue in previous versions of bind9 in lenny? 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
Bug#584911: bind9: hard-coded dependency on /usr/lib/ssl/openssl.cnf might cause trouble
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. /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
Bug#584911: bind9: hard-coded dependency on /usr/lib/ssl/openssl.cnf might cause trouble
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
Bug#578361: fixed in sun-java6 6.20-dlj-1
Thank you very much! Mirko This message contains information which may be confidential and privileged.Unless you are the intended recipient (or authorized to receive this message for the intended recipient), you may not use, copy, disseminate or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail, and delete the message. Thank you very much. (A) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578361: sun-java6-jdk (amd64): outdated version with security vulnerabilities
Package: sun-java6-jdk Version: 6-17-1 Severity: serious Tags: security Package sun-java6-jdk on sid/amd64 lags behind sid/i386 quite a bit now. That's a pity, since the current version of Sun Java has quite a list of security fixes compared to the package in sid/amd64. I'm tracking sun-java6-jdk from unstable on a system with lenny/amd64 installed, to have security support for the package (OpenJDK is currently no option, unfortunately). Will there be further development of sun-java6-jdk on amd64? Best Regards, Mirko This message contains information which may be confidential and privileged.Unless you are the intended recipient (or authorized to receive this message for the intended recipient), you may not use, copy, disseminate or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail, and delete the message. Thank you very much. (A) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
