Hello. 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 x86_64) libdir=/usr/lib64 @@ -37,8 +38,8 @@ ;; esac 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 { 192.168.200.1; }; }; 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?
CC: (none) => alien, guillomovitch
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
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).
Assignee: bugsquad => guillomovitch
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.
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 1.106.20.172.in-addr.arpa was an authoritative NXDOMAIN." I don't really get it...
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 -- 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.
Made a private bind-9.9.2-0.0.rc1.1.mga2.src.rpm (based on cauldron) and 1.) seems to be fixed now.
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.
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 :/
I strongly suggest bumping bind to 9.9.2: ftp://ftp.isc.org/isc/bind9/9.9.2/RELEASE-NOTES-BIND-9.9.2.txt It fixes (as promised by ISC) the segfault when you stop bind 1.)
Here's what I use: http://n1.nux.se/work/bind-9.9.2-0.1.mga2.src.rpm Just a few rediffs. But there's some work needed as I had to zero out two macros in the spec file.
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.
Depends on: (none) => 7762
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
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.
Status: NEW => RESOLVEDResolution: (none) => FIXED
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" /var/lib/named/usr/lib64/openssl-1.0.0j/engines/libgost.so /var/lib/named/usr/lib64/openssl-1.0.0k/engines/libgost.so To clean this up you can do: service named stop rm -rf /var/lib/named/usr/lib64/openssl* service named start
Additionally I don't know why the openssl version was upgraded in this case.
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.
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.
Well we don't want there to be problems when openssl is bumped during stable.
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.
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.
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.
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...
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.