unbound-anchor ignores net.ipv6.conf.all.disable_ipv6=1 in /etc/sysctl.conf
edmonds at debian.org
Wed Nov 4 18:21:36 CET 2015
Phil Mayers via Unbound-users wrote:
> On 04/11/2015 15:49, Tomas Hozza wrote:
> >If you have some strong technical argument for this behavior I would
> >be more than glad to hear it. The reason is that similar people will
> >fight hard against having Unbound as the default DNS resolver in
> >Fedora, which is our ultimate plan. Ability to spare hundreds of
> >emails arguing with them would be great :)
> Which "behaviour"?
> I'm honestly confused. As far as I can tell, everything is working as
> designed here.
> The code tries to open an IPv6 socket, the kernel tries to load the module,
> SELinux denies and logs this. Each of these items is by design. Which are
> you suggesting should change?
If I understand correctly, there is no ipv6.ko module on the kernel in
question that can be autoloaded; at least on my Fedora 20 and CentOS 7
machines, the kernels are built with CONFIG_IPV6=y.
When "ipv6.disable=1" is set on the kernel command line, it looks like
the (built-in) IPv6 code bails out without registering the IPv6 TCP,
UDP, etc. protocols:
So, IIUC, when a userspace program tries to create an AF_INET6 socket,
the kernel sees that the requested protocol isn't available (due to this
early bail out from the ipv6 module), and tries to load the "net-pf-10"
module, even though this would have been provided by code statically
compiled into the kernel.
Is the problem perhaps that "ipv6.disable=1" on the kernel command line
should be accompanied by "alias net-pf-10 off" in the modprobe
configuration in order to prevent useless autoloading attempts?
> Is it the audit log that is annoying people? If so, the SELinux policy
> should be a dontaudit.
I can't see how this audit message wouldn't be triggered by basically
any program that creates an IPv6 socket, which should be close to any
program that uses the network by now?
> Can we agree that unbound-anchor should not be reading sysctls to change
> it's behaviour?
I do, that's just crazy :-)
The userspace interface for detecting the lack of IPv6 support is: if
the call to socket() fails (probably with EAFNOSUPPORT or
EPROTONOSUPPORT), then it's not supported. And any sane userspace
program already checks for socket() failures.
edmonds at debian.org
More information about the Unbound-users