On 04/11/2015 17:21, Robert Edmonds wrote:
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.
Good point; that's what I see too (and an entirely sensible default it is).
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 that config read by modprobe after the kernel has called it? In which
case it'll still trigger (and deny) the probe. It's been so long since I
looked at module loading I can't remember.
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?
They might be running under SELinux contexts which either permit or
dontaudit the module load I suppose? But I agree, almost everything is
going to be v6-aware at this point.
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.
That's my understanding too. Most apps won't even end up that low-level,
having probably used getaddrinfo() to iterate across a list of sockets,
and glibc having filtered out unavailable address families before then.
