Bug 7540 - Numerous problems found in bind-9.9.1-P3
Summary: Numerous problems found in bind-9.9.1-P3
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 2
Hardware: x86_64 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Guillaume Rousse
QA Contact:
Depends on: 7762
  Show dependency treegraph
Reported: 2012-09-21 09:45 CEST by Oden Eriksson
Modified: 2013-02-14 22:55 CET (History)
4 users (show)

See Also:
Source RPM: bind-9.9.1.P3-1.mga2.src.rpm
Status comment:


Description Oden Eriksson 2012-09-21 09:45:05 CEST

I found some problems with bind-9.9.1.P3 in mga2:

1. bind (named) segfaults when stopped.

2. The needed libgost.so openssl engine is never overwritten in the chroot which could be a security problem. Here's my fix:

--- setup-named-chroot.sh       2012-09-13 20:39:18.000000000 +0200
+++ setup-named-chroot.sh.oden  2012-09-21 09:32:43.020867633 +0200
@@ -28,6 +28,7 @@
 # better always copy localtime so it respects the system's timezone
 install -m 0644 -o root -g root /etc/localtime $ROOTDIR/etc/

+# libgost.so needs to be in the chroot, so copy it there
 case $(arch) in
@@ -37,8 +38,8 @@
 version=$(rpm -q --queryformat='%{VERSION}\n' openssl)
-mkdir -p $ROOTDIR$libdir
-cp -r $libdir/openssl-$version $ROOTDIR$libdir
+[ -d $ROOTDIR$libdir/openssl-$version/engines ] || mkdir -p $ROOTDIR$libdir/openssl-$version/engines
+cp -p $libdir/openssl-$version/engines/libgost.so $ROOTDIR$libdir/openssl-$version/engines/

 [ -d $ROOTDIR/proc ] || mkdir -p $ROOTDIR/proc
 if ! egrep -q '^/proc[[:space:]]+$ROOTDIR/proc' /proc/mounts; then

3. mount --bind does not work for some unknown reason, you have to do it manually:

# mount --bind /proc /var/lib/named/proc -o ro
mount: warning: /var/lib/named/proc seems to be mounted read-write.
# mount | grep /var/lib/named/proc
proc on /var/lib/named/proc type proc (rw,relatime)

(wrong syntax for mount?)

4. If the mount should had worked a restart would probably mount it again. I looked at fedora and their chroot script seems saner, however they don't seem to use a mount bound /proc in the chroot OR the needed libgost.so openssl engine.

5. A forward statement like this does NOT work:

zone "101.200.172.in-addr.arpa" IN {
    type forward;
    forward only;
    forwarders {; };

I rebuilt bind-9.8.3P3-1.mga1.src.rpm on mga2 and this version DOES work.

I'm not really up to date with BIND these days, maybe /proc and libgost.so is not needed anymore?
AL13N 2012-09-21 09:58:03 CEST

CC: (none) => alien, guillomovitch

Comment 1 David Walser 2012-09-21 14:07:13 CEST
A lot of different issues here.

For issues #1 and #5, have you tested previous versions of the Mageia 2 package to see which ones are affected?  Have you tested Cauldron (same BIND version) to see if you can reproduce there?  Both of these could potentially be upstream issues.

Issue #2/4 is a packaging issue, but as you mentioned it might not be needed, so this should be tested.

Issue #3, I don't quite follow you...

CC: (none) => luigiwalser

Comment 2 Oden Eriksson 2012-09-22 10:04:27 CEST
No, I have not tested any of the previous 9.9.1 versions as in 5.)

And no, I have not tested any other systemd distro where bind is under systemd control. I saw that latest opensuse has the latest bind 9.9.1 in updates, maybe they also have the 5.) problem?

For 3.) you must look in /usr/sbin/setup-named-chroot.sh where it attempts to mount --bind /proc (but fails here). There is no logic to unmount the mount bound /proc there, so it will be mounted over and over again for each time you restart named (if it had worked).
Manuel Hiebel 2012-09-23 20:54:12 CEST

Assignee: bugsquad => guillomovitch

Comment 3 Oden Eriksson 2012-09-25 07:52:35 CEST
For 5.) a temporary work around is to add this in "options" in named.conf:

empty-zones-enable no;

This problem has been reported upstream and is being worked on.
Comment 4 Oden Eriksson 2012-09-26 10:53:09 CEST
More info from ISC:

1.) will be fixed with 9.9.2

5.) is not a bug according to ISC:

"Forwarding only occurs when the nameserver would have to perform iterative
resolution in order to respond to a query where it doesn't have the answer
available either from the zones for which it is authoritative, or already held
in cache. In this instance your nameserver was authoritative for
20.172.in-addr.arpa - so the correct response to a query for was an authoritative NXDOMAIN."

I don't really get it...
Comment 5 Oden Eriksson 2012-09-26 11:30:16 CEST
Additionally, this is ISC-Bug #31117

And, they still think 5.) is not a bug. Well...

"BIND 9.9.0 turned on RFC 6303 support for all listed prefixes
including all RFC 1918 prefixes.  This is a good thing as most users
of RFC 1918 address space do not configure the corresponding
IN-ADDR.ARPA zones and leak queries to the internet as a whole.
This has required others to deploy sacrificial servers to shift the
queries away from the IN-ADDR.ARPA servers.

Unfortunately some old configurations will require changes.  Yours
happens to be one of them.

* 106.20.172.in-addr.arpa could be turned from a forward zone into
  a stub zone.  This assumes 106.20.172.in-addr.arpa is a actual zone
  and not just part of 20.172.in-addr.arpa.
* 20.172.in-addr.arpa could be added to named.conf and 106.20.172.in-addr.arpa
  could be delegated from it.
* 106.20.172.in-addr.arpa could be turned into a slave zone.  This
  assumes 106.20.172.in-addr.arpa is a actual zone.
* you can just disable the 20.172.in-addr.arpa empty zone instance.
* you can just disable all empty zones.

Mark Andrews, ISC"

So, if some Mageia user can't get reverse pointers to resolve for their private RFC 1918 network(s), my advice is to disable empty-zones per zone.
Comment 6 Oden Eriksson 2012-09-28 11:50:20 CEST
Made a private bind-9.9.2-0.0.rc1.1.mga2.src.rpm (based on cauldron) and 1.) seems to be fixed now.
Comment 7 Oden Eriksson 2012-09-28 13:37:00 CEST
A follow up on the 5.) problem.

ISC just posted: https://kb.isc.org/article/AA-00800

And it's clear now, even though your server is authorative for 106.20.172.in-addr.arpa the checks goes deeper than that. As I understand it you now also have to be authorative for 172.20 as well, ie recursively.

So, it's not a bug but a feature.
Comment 8 Guillaume Rousse 2012-10-07 13:19:00 CEST
For issues 2, 3 and 4, I'm considering switching to the fedora chroot script, to make future maintainance easier. Especially given the growing complexity of bind with DNSSEC. However, it also requires file layout changes, as it relies on moving the actual files on the normal system, and using bind mount in the chroot, whereas we currently have actual files in the chroot, with symlinks from the normal system. Which means dedicated handling during upgrade...

That's out of scope of an update for mageia 2, tough :/
Comment 9 Oden Eriksson 2012-10-10 14:16:57 CEST
I strongly suggest bumping bind to 9.9.2:


It fixes (as promised by ISC) the segfault when you stop bind 1.)
Comment 10 Oden Eriksson 2012-10-10 14:19:37 CEST
Here's what I use:


Just a few rediffs. But there's some work needed as I had to zero out two macros in the spec file.
Comment 11 David Walser 2012-10-10 14:28:33 CEST
In principle I have no objections, since it is still 9.9 stable branch.

First let's get it into Cauldron and get some testing there.
David Walser 2012-10-10 16:35:41 CEST

Depends on: (none) => 7762

Comment 12 Daniel Lucio 2013-02-14 01:44:03 CET
Issue number 2 happens. But Oden's solution doesn't seem to apply since I understand we use bind mounts. I mean it will work, but I don't know if it is best solution according policy.

If we do s
Mount --bind $libdir/openssl-$version $ROOTDIR/$libdir/openssl-$version

Will it work inside chroot?

CC: (none) => dlucio

Comment 13 Oden Eriksson 2013-02-14 10:41:05 CET
All these issues were fixed in https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0354 except for 5.) that should be handled on a case-by-case basis and not with a "fix" in the mga2 package.

For mga3 someone decided to use the fedora package where nothing of this applies except for 5.).

Closing as FIXED.

Resolution: (none) => FIXED

Comment 14 Oden Eriksson 2013-02-14 15:09:27 CET
Additional info. The /usr/sbin/setup-named-chroot.sh script is executed when you start named. The last 3 lines does this:

version=$(rpm -q --queryformat='%{VERSION}\n' openssl)
mkdir -p $ROOTDIR$libdir/openssl-$version/engines
cp -p $libdir/openssl-$version/engines/libgost.so $ROOTDIR$libdir/openssl-$version/engines/

This leaves stray libgost.so files around but this is harmless. Eg:

[root@localhost /]# find /var/lib/named/usr/lib64/ -type f -name "libgost.so"

To clean this up you can do:

service named stop
rm -rf /var/lib/named/usr/lib64/openssl*
service named start
Comment 15 Oden Eriksson 2013-02-14 15:11:37 CET
Additionally I don't know why the openssl version was upgraded in this case.
Comment 16 David Walser 2013-02-14 15:38:33 CET
He originally reported the issue for Cauldron, so you do know why that one was upgraded.  As for Mageia 2, normally we patch on stable rather than upgrading openssl.  Granted, upgrading it *shouldn't* cause any problems, but Funda handled that one (as well as gnutls which he also upgraded for some reason) and they were pushed as updates before I even realized they had gone to QA.
Comment 17 Oden Eriksson 2013-02-14 16:28:24 CET
Ah, I thought this was for mga2.

For mga3:

I'm guessing a restart of the named server is required if you bump the openssl version. Because the old (and loaded) libgost.so will vanish from the harddrive and the new openssl libs will use the new libgost.so file. eg. /usr/lib64/openssl/1.0.1d/engines/libgost.so will vanish and /usr/lib64/openssl/1.0.1e/engines/libgost.so will be added.

I think there is some mechanism in some rpm scripts to advice that a reboot is needed when for example installing (rpm -Uvh) glibc. Maybe there is a way to trigger a restart of the named server when the openssl version has been upgraded? But then, this should be done for many softwares as particulary the openssl libs are known to be quite problematic in that sense. Quite often in the past when bumping openssl (like openssl-0.9.8a -> openssl-0.9.8b) in cooker you ended up with a non working ssh server, until you had rebuilt openssh against the new openssl version.

I don't know at what lenght you want to go to really fix this.
Comment 18 David Walser 2013-02-14 16:29:37 CET
Well we don't want there to be problems when openssl is bumped during stable.
Comment 19 Oden Eriksson 2013-02-14 16:56:07 CET
OK. Then I would advice you to rebuild at least openssh each time you bump openssl and push these at the same time so it's a little safer for remote headless boxes. Also a full reboot is adviced. In that order. There's no guarantee you have to do it or not.

The other way is to cherry-pick packages that are known to be picky with the openssl version and restart these somehow. Some softwares has (or had?) built in runtime checks for the openssl version but I think this was disabled a long time ago because it was too inconvenient, thus effectively hiding the problem.

I can only give recommendations here, not spend an unknown amount of time fixing it, sorry.
Comment 20 David Walser 2013-02-14 16:59:59 CET
I wish software/packages weren't so brittle in this way.  I guess it's a lucky (?) thing we had to issue an openssh security update yesterday, so that's rebuilt.
Comment 21 Oden Eriksson 2013-02-14 17:14:58 CET
As for ssh it's easy, either the ssh server starts or not. If it don't start it has to be rebuilt. When this happens it's a good sign other and in particular crucial server softwares linking against the openssl libs should be rebuilt as well. But there's no guarantee you have to. I have no real-life experience of this scenario however, how it will affect a running server, if it gradually degrades in performance and finally dies. I'd rather be safe than sorry, that's one of the reasons I took care of the mass rebuilds in mdv. I'm happy this is done per policy in mga.
Comment 22 AL13N 2013-02-14 22:41:20 CET
maybe we should try to patch libraries such as these, then instead of bumping the version? maybe a policy for that would be nice? if not, then we'd have to make a list of packages per library to build at the same time, so that this doesn't happen again...

perhaps it might be possible to extend spec files and add a entry about packages-to-be-rebuilt and have the buildsystem rebuild those automagically...
Comment 23 David Walser 2013-02-14 22:55:45 CET
We usually do patch openssl, but Funda updated it.  Anyway, if the library is supposed to remain binary compatible, which openssl should, it shouldn't require anything else be fixed or rebuilt.

Note You need to log in before you can comment on or make changes to this bug.