Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 321071 - net-dns/bind-9.6, 9.7 /dev/random mount-bind
Summary: net-dns/bind-9.6, 9.7 /dev/random mount-bind
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: BIND Maintainers (DISABLED)
Depends on:
Reported: 2010-05-22 17:54 UTC by Duncan
Modified: 2010-08-26 16:49 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Duncan 2010-05-22 17:54:49 UTC
This is a follow-on to bug #275684, which updated bind's chroot.  I like it, but there's something missing: a /dev/random mount-bind.

The partition (root) I have the chroot on is mounted nodev.  Normally active device-nodes aren't needed in operation because udev takes care of that, and that's its own filesystem, obviously NOT mounted nodev. =:^)  As udev starts well before the root remount, basic console devices on root work just fine until after udev takes over.

So the named initscript needs to mount-bind /dev/random (or urandom, as appropriate) into the chroot as well, as existing device nodes in the chroot won't work.  At present, I get a log entry at ever named start saying it can't use the chroot random device, it's using the pre-chroot device.  That works, but it's annoying, and should be easy enough to fix.

Here's an /etc/init.d/named patch.  This simply does the mount-bind.  In testing, I noticed that the file (not dir) had to be there to bind.  Simply touching it works, but I didn't see any checking for mountpoint existence on the others, so the initscript would appear to be somewhat brittle in that regard, and this doesn't change that.  I'd prefer that all mountpoints were checked and created if necessary, in case something happened to them since the initial ebuild config step.  If you want a patch for that, ask (and specify if you want it here or on a new bug).

Also, I didn't know what to do about the random/urandom thing, as that appears to be ebuild install/configure time only and I don't know how you'd want to hook that option for the initscript.  Maybe add a setting to /etc/conf.d/named?  Or they could both be mount-bound into the chroot.

So this patch is likely a bit simpler than what'll be needed, but as a demonstration of concept, it does the trick for me.  No more logged named complaints about inability to access the chrooted random device. =:^)

--- init.d/named.orig  2010-05-22 10:22:39.000000000 -0700
+++ init.d/named       2010-05-22 10:24:17.000000000 -0700
@@ -78,6 +78,7 @@ start() {
                _mount /etc/bind ${CHROOT}/etc/bind -o bind
                _mount /var/bind ${CHROOT}/var/bind -o bind
                _mount /var/log/named ${CHROOT}/var/log/named -o bind
+               _mount /dev/random ${CHROOT}/dev/random -o bind
        checkconfig || return 1

Meanwhile, I had no complaint logged about /dev/zero, so either my setup (simple caching server, delegation-onlys, etc) isn't advanced enough to use whatever uses that, or it isn't needed any more.  That's why the patch above doesn't do a mount-bind for it as well.
Comment 1 Christian Ruppert (idl0r) gentoo-dev 2010-05-23 20:53:54 UTC
(u)random will be defined during compile time (fixed/static) except _maybe_ you change it through the random-device option.
Its used for e.g. dnssec.

/dev/zero and null are still suggested by the bind docs so I'll leave it as it is.

The init script checks now the important files/dirs in the chroot dir and complains if some are missing.
There is also a warning that you should run "emerge --config bind" again.

So please test bind-9.6.2_p2 or bind-9.7.0_p2-r1.
Comment 2 Duncan 2010-05-24 01:53:08 UTC
Fast turn-around! =:^)

I see another bug tracing this, but will file it separately...  After working around it...

The config works as far as it goes, but doesn't solve my problem.

As I mentioned, the filesystem (root) that the chroot is on is mounted nodev. This is fine for everything else since other than this chroot, everything using device-files is using /dev, which is udev and therefore its own filesystem.  As there's no (other) legit need for device-files on root, a conservative security policy says it should be mounted nodev, which it is.

So then here we have this chroot.  The mknodes do indeed make the char-devs, and the [[ -c ]] tests verify them as such, but when they try to get used, the kernel returns permission errors since the filesystem is mounted nodev.

That's why I suggested bind-mounting the individual device-files as well.  That way, they get the same permissions as their parent filesystem, udev, which of course is NOT mounted nodev, so the devices work, while those on the native filesystem hosting the chroot don't work because it's mounted nodev.

FWIW, thanks for the work.  If you decide the config is simply too strange to handle at your end, I'll handle it at mine.  But of course, that means maintaining changes to the /etc/init.d/named file, ensuring they don't get lost at every update, so if it's possible to have Gentoo's scripts "just work" with it, that'd be great. =:^)
Comment 3 Christian Ruppert (idl0r) gentoo-dev 2010-05-26 19:38:52 UTC
I'm still thinking about it but I'm not sure if we really shall mount devices too...
So currently it looks like we don't change the current behaviour.
Comment 4 Christian Ruppert (idl0r) gentoo-dev 2010-08-26 16:49:16 UTC
"nodev  Do not interpret character or block special devices on the file system."
So it wouldn't work even if we mount it into the chroot.