2012-12-06 17:20:39 +00:00
|
|
|
##WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
|
|
|
|
##OVERWRITTEN AND LOST. Changes to this configuration should be made using:
|
|
|
|
## virsh net-edit private
|
2012-12-12 22:03:40 +00:00
|
|
|
## or other application using the libvirt API.
|
2012-12-06 17:20:39 +00:00
|
|
|
##
|
|
|
|
## dnsmasq conf file created by libvirt
|
|
|
|
strict-order
|
|
|
|
except-interface=lo
|
network: prevent dnsmasq from listening on localhost
This patch resolves the problem reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=886663
The source of the problem was the fix for CVE 2011-3411:
https://bugzilla.redhat.com/show_bug.cgi?id=833033
which was originally committed upstream in commit
753ff83a50263d6975f88d6605d4b5ddfcc97560. That commit improperly
removed the "--except-interface lo" from dnsmasq commandlines when
--bind-dynamic was used (based on comments in the latter bug).
It turns out that the problem reported in the CVE could be eliminated
without removing "--except-interface lo", and removing it actually
caused each instance of dnsmasq to listen on localhost on port 53,
which created a new problem:
If another instance of dnsmasq using "bind-interfaces" (instead of
"bind-dynamic") had already been started (or if another instance
started later used "bind-dynamic"), this wouldn't have any immediately
visible ill effects, but if you tried to start another dnsmasq
instance using "bind-interfaces" *after* starting any libvirt
networks, the new dnsmasq would fail to start, because there was
already another process listening on port 53.
(Subsequent to the CVE fix, another patch changed the network driver
to put dnsmasq options in a conf file rather than directly on the
dnsmasq commandline, but preserved the same options.)
This patch changes the network driver to *always* add
"except-interface=lo" to dnsmasq conf files, regardless of whether we use
bind-dynamic or bind-interfaces. This way no libvirt dnsmasq instances
are listening on localhost (and the CVE is still fixed).
The actual code change is miniscule, but must be propogated through all
of the test files as well.
2012-12-13 06:46:40 +00:00
|
|
|
bind-interfaces
|
2012-12-06 17:20:39 +00:00
|
|
|
listen-address=192.168.152.1
|
|
|
|
dhcp-option=3
|
|
|
|
no-resolv
|
network: add netmask to dhcp range of dnsmasq conf file for IPv4
dnsmasq documentation says that the *IPv4* prefix/network
address/broadcast address sent to dhcp clients will be automatically
determined by dnsmasq by looking at the interface it's listening on,
so the original libvirt code did not add a netmask to the dnsmasq
commandline (or later, the dnsmasq conf file).
For *IPv6* however, dnsmasq apparently cannot automatically determine
the prefix (functionally the same as a netmask), and it must be
explicitly provided in the conf file (as a part of the dhcp-range
option). So many years after IPv4 DHCP support had been added, when
IPv6 dhcp support was added the prefix was included at the end of the
dhcp-range setting, but only for IPv6.
A user had reported a bug on a host where one of the interfaces was a
superset of the libvirt network where dhcp is needed (e.g., the host's
ethernet is 10.0.0.20/8, and the libvirt network is 10.10.0.1/24). For
some reason dnsmasq was supplying the netmask for the /8 network to
clients requesting an address on the /24 interface.
This seems like a bug in dnsmasq, but even if/when it gets fixed
there, it looks like there is no harm in just always adding the
netmask to all IPv4 dhcp-range options similar to how prefix is added
to all IPv6 dhcp-range options.
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2019-02-18 21:34:50 +00:00
|
|
|
dhcp-range=192.168.152.2,192.168.152.254,255.255.255.0
|
2012-12-06 17:20:39 +00:00
|
|
|
dhcp-no-override
|
2016-09-21 08:49:41 +00:00
|
|
|
dhcp-authoritative
|
2012-12-06 17:20:39 +00:00
|
|
|
dhcp-lease-max=253
|
|
|
|
dhcp-hostsfile=/var/lib/libvirt/dnsmasq/private.hostsfile
|
|
|
|
addn-hosts=/var/lib/libvirt/dnsmasq/private.addnhosts
|