Summary: | net-dns/bind-9.6, 9.7 /dev/random mount-bind | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Duncan <1i5t5.duncan> |
Component: | [OLD] Server | Assignee: | BIND Maintainers (DISABLED) <bind+disabled> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Duncan
2010-05-22 17:54:49 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. 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. =:^) 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. "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. |