- 21 12月, 2012 4 次提交
-
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 18 12月, 2012 2 次提交
-
-
由 Laine Stump 提交于
This is yet another refinement to the fix for CVE-2012-3411: https://bugzilla.redhat.com/show_bug.cgi?id=833033 It turns out that it would be very intrusive to correctly backport the entire --bind-dynamic option to older dnsmasq versions (e.g. dnsmasq-2.48 that is used on RHEL6.x and CentOS 6.x), but very simple to patch those versions to just use SO_BINDTODEVICE on all their listening sockets (SO_BINDTODEVICE also has the desired effect of permitting only traffic that was received on the interface(s) where dnsmasq was set to listen.) This patch modifies the dnsmasq capabilities detection to detect the string: --bind-interfaces with SO_BINDTODEVICE in the output of "dnsmasq --version", and in that case realize that using the old --bind-interfaces option is just as safe as --bind-dynamic (and therefore *not* forbid creation of networks that use public IP address ranges). If -bind-dynamic is available, it is still preferred over --bind-interfaces. Note that this patch does no harm in upstream, or in any distro's downstream if it happens to end up there, but builds for distros that have a new enough dnsmasq to support --bind-dynamic do *NOT* need to specifically backport this patch; it's only required for distro releases that have dnsmasq too old to have --bind-dynamic (and those distros will need to add the SO_BINDTODEVICE patch to dnsmasq, *including the extra string in the --version output*, as well.
-
由 Laine Stump 提交于
Somehow I managed to push the changes to this file with improper indentation. This patch just re-indents, reformats the comment lines, and re-groups a couple of multi-line strings so that they fit within 80 columns. The resulting binary should be identical.
-
- 15 12月, 2012 1 次提交
-
-
由 Laine Stump 提交于
A forgotten "!" in recently-modified code at the top of networkRefreshDaemon() meant an improper early return, which led to 1) dnsmasq config files not being updated from the newly modified config, and 2) dnsmasq not being sent a SIGHUP so that it could learn about the changes to the config. virNetworkDefGetIpByIndex() returns NULL if there are no ip objects of the requested type, and if there are no IP elements, then dnsmasq shouldn't be running, so we can return early. Otherwise we should rewrite the config files and send a SIGHUP.
-
- 14 12月, 2012 1 次提交
-
-
由 Laine Stump 提交于
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 753ff83a. 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.
-
- 13 12月, 2012 1 次提交
-
-
由 Eric Blake 提交于
I noticed that /var/lib/libvirt/dnsmasq/*.conf used the wrong word; it was intended to match the wording in src/util/xml.c. * src/network/bridge_driver.c (networkDnsmasqConfContents): Fix typo. * tests/networkxml2confdata/*.conf: Update accordingly.
-
- 12 12月, 2012 3 次提交
-
-
由 Michal Privoznik 提交于
Currently, we are only keeping a inactive XML configuration in status dir. This is no longer enough as we need to keep this class_id attribute so we don't overwrite old entries when the daemon restarts. However, since there has already been release which has just <network/> as root element, and we want to keep things compatible, detect that loaded status file is older one, and don't scream about it.
-
由 Michal Privoznik 提交于
Network should be notified if we plug in or unplug an interface, so it can perform some action, e.g. set/unset network part of QoS. However, we are doing this in very early stage, so iface->ifname isn't filled in yet. So whenever we want to report an error, we must use a different identifier, e.g. the MAC address.
-
由 Michal Privoznik 提交于
These classes can borrow unused bandwidth. Basically, only egress qdsics can have classes, therefore we can do this kind of traffic shaping only on host's outgoing, that is domain's incoming traffic.
-
- 11 12月, 2012 5 次提交
-
-
由 Gene Czarcinski 提交于
This patch changes how parameters are passed to dnsmasq. Instead of being on the command line, the parameters are put into a file (one parameter per line) and a commandline --conf-file= specifies the location of the file. The file is located in the same directory as the leases file. Putting the dnsmasq parameters into a configuration file allows them to be examined and more easily understood than examining the command lines displayed by "ps ax". This is especially true when a number of networks have been started. When the use of dnsmasq was originally done, the required command line was simple, but it has gotten more complicated over time and will likely become even more complicated in the future. Note: The test conf files have all been renamed .conf instead of .argv, and tests/networkxml2xmlargvdata was moved to tests/networkxml2xmlconfdata.
-
由 Gene Czarcinski 提交于
The DHCPv6 support includes IPV6 dhcp-range and dhcp-host for one IPv6 subnetwork on one interface. This support will only work if dnsmasq version >= 2.64; otherwise an error occurs if dhcp-range or dhcp-host is specified for an IPv6 address. Essentially, this change provides the same DHCP support for IPv6 that has been available for IPv4. With dnsmasq >= 2.64, support for the RA service is also now provided by dnsmasq (radvd is no longer used/started). (Although at least one version of dnsmasq prior to 2.64 "supported" IPv6 Router Advertisement, there were bugs (fixed in 2.64) that rendered it unusable.) Documentation and the network schema has been updated to reflect the new support.
-
由 Laine Stump 提交于
The attributes of a <network> element's <forward> element were previously stored directly in the virNetworkDef object, but virNetworkUpdateForward() needs to operate on a <forward> in isolation, so this patchs pulls out all those attributes into a separate virNetworkForwardDef struct (and shortens their names appropriately). This new object is contained in the virNetworkDef, not pointed to by it, so there is no extra memory management. This patch makes no functional changes, it only changes, e.g., "nForwardIfs" to "forward.nifs".
-
由 Laine Stump 提交于
Since there is only a single virNetworkDNSDef for any virNetworkDef, and it's trivial to determine whether or not it contains any real data, it's much simpler (and fits more uniformly with the parse function calling sequence of the parsers for many other objects that are subordinates of virNetworkDef) if virNetworkDef *contains* an virNetworkDNSDef rather than pointing to one. Since it is now just a part of another object rather than its own object, it no longer makes sense to have a *Free() function, so that is changed to a *Clear() function. More importantly though, ParseXML and Clear functions are needed for the individual items contained in a virNetworkDNSDef (srv, txt, and host records), but none of them have a *Clear(), and only two of the three had *ParseXML() functions (both of which used a non-uniform arglist). Those problems are cleared up by this patch - it splits the higher-level Clear function into separate functions for each of the three, creates a parse for txt records, and cleans up the srv and host parsers, so we now have all the utility functions necessary to implement virNetworkDefUpdateDNS(Host|Srv|Txt).
-
由 Laine Stump 提交于
This shortens the name of the structs for srv and txt, and their instances in virNetworkDNSDef, to be more compact and uniform with the naming of the dns host array. It also changes the type of ntxts, etc from unsigned int to size_t, so that they can be used directly as args to VIR_*_ELEMENT.
-
- 06 12月, 2012 2 次提交
-
-
由 Laine Stump 提交于
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=767057 It was possible to define a network with <forward mode='bridge'> that had both a bridge device and a forward device defined. These two are mutually exclusive by definition (if you are using a bridge device, then this is a host bridge, and if you have a forward dev defined, this is using macvtap). It was also possible to put <ip>, <dns>, and <domain> elements in this definition, although those aren't supported by the current driver (although it's conceivable that some other driver might support that). The items that are invalid by definition, are now checked in the XML parser (since they will definitely *always* be wrong), and the others are checked in networkValidate() in the network driver (since, as mentioned, it's possible that some other network driver, or even this one, could some day support setting those).
-
由 Gene Czarcinski 提交于
This patch adds the capability for virtual guests to do IPv6 communication via a virtual network interface with no IPv6 (gateway) addresses specified. This capability has always been enabled by default for IPv4, but disabled for IPv6 for security concerns, and because it requires the ip6tables command to be operational (which isn't the case on a system with the ipv6 module completely disabled). This patch adds a new attribute "ipv6" at the toplevel of a <network> object. If ipv6='yes', the extra ip6tables rules required to permite inter-guest communications are added when the network is started. If it is 'no', or not present, those rules will not be added; thus the default behavior doesn't change, so there should be no compatibility issues with any existing installations. Note that virtual guests cannot communication with the virtualization host via this interface, because the following kernel tunable has been set: net.ipv6.conf.<bridge_interface_name>.disable_ipv6 = 1 This assures that the bridge interface will not have an IPv6 link-local (fe80::) address. To control this behavior so that it is not enabled by default, the parameter ipv6='yes' on the <network> statement has been added. Documentation related to this patch has been updated. The network schema has also been updated.
-
- 04 12月, 2012 2 次提交
-
-
由 Daniel P. Berrange 提交于
Currently to deal with auto-shutdown libvirtd must periodically poll all stateful drivers. Thus sucks because it requires acquiring both the driver lock and locks on every single virtual machine. Instead pass in a "inhibit" callback to virStateInitialize which drivers can invoke whenever they want to inhibit shutdown due to existance of active VMs. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The only important state that should prevent libvirtd shutdown is from running VMs. Networks, host devices, network filters and storage pools are all long lived resources that have no significant in-memory state. They should not block shutdown.
-
- 30 11月, 2012 3 次提交
-
-
由 Laine Stump 提交于
This bug resolves CVE-2012-3411, which is described in the following bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=833033 The following report is specifically for libvirt on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=874702 In short, a dnsmasq instance run with the intention of listening for DHCP/DNS requests only on a libvirt virtual network (which is constructed using a Linux host bridge) would also answer queries sent from outside the virtualization host. This patch takes advantage of a new dnsmasq option "--bind-dynamic", which will cause the listening socket to be setup such that it will only receive those requests that actually come in via the bridge interface. In order for this behavior to actually occur, not only must "--bind-interfaces" be replaced with "--bind-dynamic", but also all "--listen-address" options must be replaced with a single "--interface" option. Fully: --bind-interfaces --except-interface lo --listen-address x.x.x.x ... (with --listen-address possibly repeated) is replaced with: --bind-dynamic --interface virbrX Of course libvirt can't use this new option if the host's dnsmasq doesn't have it, but we still want libvirt to function (because the great majority of libvirt installations, which only have mode='nat' networks using RFC1918 private address ranges (e.g. 192.168.122.0/24), are immune to this vulnerability from anywhere beyond the local subnet of the host), so we use the new dnsmasqCaps API to check if dnsmasq supports the new option and, if not, we use the "old" option style instead. In order to assure that this permissiveness doesn't lead to a vulnerable system, we do check for non-private addresses in this case, and refuse to start the network if both a) we are using the old-style options, and b) the network has a publicly routable IP address. Hopefully this will provide the proper balance of not being disruptive to those not practically affected, and making sure that those who *are* affected get their dnsmasq upgraded. (--bind-dynamic was added to dnsmasq in upstream commit 54dd393f3938fc0c19088fbd319b95e37d81a2b0, which was included in dnsmasq-2.63)
-
由 Laine Stump 提交于
In order to optionally take advantage of new features in dnsmasq when the host's version of dnsmasq supports them, but still be able to run on hosts that don't support the new features, we need to be able to detect the version of dnsmasq running on the host, and possibly determine from the help output what options are in this dnsmasq. This patch implements a greatly simplified version of the capabilities code we already have for qemu. A dnsmasqCaps device can be created and populated either from running a program on disk, reading a file with the concatenated output of "dnsmasq --version; dnsmasq --help", or examining a buffer in memory that contains the concatenated output of those two commands. Simple functions to retrieve capabilities flags, the version number, and the path of the binary are also included. bridge_driver.c creates a single dnsmasqCaps object at driver startup, and disposes of it at driver shutdown. Any time it must be used, the dnsmasqCapsRefresh method is called - it checks the mtime of the binary, and re-runs the checks if the binary has changed. networkxml2argvtest.c creates 2 "artificial" dnsmasqCaps objects at startup - one "restricted" (doesn't support --bind-dynamic) and one "full" (does support --bind-dynamic). Some of the test cases use one and some the other, to make sure both code pathes are tested.
-
由 Daniel P. Berrange 提交于
The virStateInitialize method and several cgroups methods were using an 'int privileged' parameter or similar for dual-state values. These are better represented with the bool type. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 28 11月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 02 11月, 2012 7 次提交
-
-
由 Daniel P. Berrange 提交于
The libvirt coding standard is to use 'function(...args...)' instead of 'function (...args...)'. A non-trivial number of places did not follow this rule and are fixed in this patch. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Peter Krempa 提交于
When assigning the new persistent definition for a transient network (thus making it persistent) the network needs to be marked persistent before actually atempting to assign the definition.
-
由 Peter Krempa 提交于
Until now, the network undefine API was able to undefine only inactive networks. The restriction doesn't make sense any more so this patch implements changing networks to transient.
-
由 Peter Krempa 提交于
When a transient network was created some of the checks weren't run on the definition allowing to start invalid networks. This patch splits out code to the network validation function and re-uses that code when creating transient networks.
-
由 Peter Krempa 提交于
The network driver didn't care about config files when a network was destroyed, just when it was undefined leaving behind files for transient networks. This patch splits out the cleanup code to a helper function that handles the cleanup if the inactive network object is being removed and re-uses this code when getting rid of inactive networks.
-
由 Peter Krempa 提交于
The hosts file was created in the network definition function. This patch moves the place the file is being created to the point where dnsmasq is being started.
-
由 Peter Krempa 提交于
The argument check_active is used only as a boolean so this patch changes the type and updates callers.
-
- 31 10月, 2012 1 次提交
-
-
由 Gene Czarcinski 提交于
Three FORWARD chain rules are added and two INPUT chain rules are added when a network is started but only the FORWARD chain rules are removed when the network is destroyed.
-
- 26 10月, 2012 1 次提交
-
-
由 Laine Stump 提交于
This was found during testing of the fix for: https://bugzilla.redhat.com/show_bug.cgi?id=868483 networkValidate was supposed to check for the existence of multiple portgroups and report an error if this was encountered. It did, but there were two problems: 1) even though it logged an error, it still returned success, allowing the operation to continue. 2) It could exit the portgroup checking loop early (or possibly not even do it once) if a vlan tag was supplied in the base network config or one of the portgroups. This patch fixes networkValidate to return failure in addition to logging the error, and also changes it to not exit the portgroup checking loop early. The logic was a bit off in the checking for vlan anyway, and it's intertwined with fixing the early loop exit, so I fixed that as well. Now it correctly checks for combinations where a <virtualport> is specified in the base network def and <vlan> is given in a portgroup, as well as the opposite (<vlan> in base network def and <virtualport> in portgroup), and ignores the case of a disallowed vlan when using *no* portgroup if there is a default portgroup (since in that case there is no way to not use any portgroup).
-
- 21 10月, 2012 2 次提交
-
-
由 Laine Stump 提交于
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=868483 virNetworkUpdate, virNetworkDefine, and virNetworkCreate all three allow network definitions to contain multiple <portgroup> elements with default='yes'. Only a single default portgroup should be allowed for each network. This patch updates networkValidate() (called by both virNetworkCreate() and virNetworkDefine()) and virNetworkDefUpdatePortGroup (called by virNetworkUpdate() to not allow multiple default portgroups.
-
由 Laine Stump 提交于
This fixes the problem reported in: https://bugzilla.redhat.com/show_bug.cgi?id=868389 Previously, the dnsmasq hosts file (used for static dhcp entries, and addnhosts file (used for additional dns host entries) were only created/referenced on the dnsmasq commandline if there was something to put in them at the time the network was started. Once we can update a network definition while it's active (which is now possible with virNetworkUpdate), this is no longer a valid strategy - if there were 0 dhcp static hosts (resulting in no reference to the hosts file on the commandline), then one was later added, the commandline wouldn't have linked dnsmasq up to the file, so even though we create it, dnsmasq doesn't pay any attention. The solution is to just always create these files and reference them on the dnsmasq commandline (almost always, anyway). That way dnsmasq can notice when a new entry is added at runtime (a SIGHUP is sent to dnsmasq by virNetworkUdpate whenever a host entry is added or removed) The exception to this is that the dhcp static hosts file isn't created if there are no lease ranges *and* no static hosts. This is because in this case dnsmasq won't be setup to listen for dhcp requests anyway - in that case, if the count of dhcp hosts goes from 0 to 1, dnsmasq will need to be restarted anyway (to get it listening on the dhcp port). Likewise, if the dhcp hosts count goes from 1 to 0 (and there are no dhcp ranges) we need to restart dnsmasq so that it will stop listening on port 67. These special situations are handled in the bridge driver's networkUpdate() by checking for ((bool) nranges||nhosts) both before and after the update, and triggering a dnsmasq restart if the before and after don't match.
-
- 20 10月, 2012 1 次提交
-
-
由 Laine Stump 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=866364 pointed out a crash due to virNetworkObjAssignDef free'ing network->newDef without NULLing it afterward. A fix for this is in upstream commit b7e92024. While the NULLing of newDef was a legitimate fix, newDef should have already been empty (NULL) anyway (as indicated in the comment that was deleted by that commit). The reason that newDef had a non-NULL value (i.e. the root cause) was that networkStartNetwork() had failed after populating network->newDef, but then neglected to free/NULL newDef in the cleanup. (A bit of background here: network->newDef should contain the persistent config of a network when a network is active (and of course only when it is persisten), and NULL at all other times. There is also a network->def which should contain the persistent definition of the network when it is inactive, and the current live state at all other times. The idea is that you can make changes to network->newDef which will take effect the next time the network is restarted, but won't mess with the current state of the network (virDomainObj has a similar pair of virDomainDefs that behave in the same fashion). Personally I think there should be a network->live and network->config, and the location of the persistent config should *always* be in network->config, but that's for a later cleanup). Since I love things to be symmetric, I created a new function called virNetworkObjUnsetDefTransient(), which reverses the effects of virNetworkObjSetDefTransient(). I don't really like the name of the new function, but then I also didn't really like the name of the old one either (it's just named that way to match a similar function in the domain conf code).
-
- 15 10月, 2012 2 次提交
-
-
由 Eric Blake 提交于
Detected with: git grep ';;$' -- '**/*.[ch]' * src/network/bridge_driver.c (networkRadvdConfContents): Fix harmless typo. * src/phyp/phyp_driver.c (phypUUIDTable_Pull): Likewise. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONDriveDel): Likewise.
-
由 Laine Stump 提交于
This function really should have been taking virDevicePCIAddress* instead of the inefficient virDevicePCIAddress (results in copying two entire structs onto the stack rather than just two pointers), and returning a bool true/false (not matching is not necessarily a "failure", as a -1 return would imply, and also using "if (!virDevicePCIAddressEqual(x, y))" to mean "if x == y" is just a bit counterintuitive).
-
- 28 9月, 2012 1 次提交
-
-
由 Benjamin Cama 提交于
I hit this problem recently when trying to create a bridge with an IPv6 address on a 3.2 kernel: dnsmasq (and, further, radvd) would not bind to the given address, waiting 20s and then giving up with -EADDRNOTAVAIL (resp. exiting immediately with "error parsing or activating the config file", without libvirt noticing it, BTW). This can be reproduced with (I think) any kernel >= 2.6.39 and the following XML (to be used with "virsh net-create"): <network> <name>test-bridge</name> <bridge name='testbr0' /> <ip family='ipv6' address='fd00::1' prefix='64'> </ip> </network> (it happens even when you have an IPv4, too) The problem is that since commit [1] (which, ironically, was made to “help IPv6 autoconfiguration”) the linux bridge code makes bridges behave like “real” devices regarding carrier detection. This makes the bridges created by libvirt, which are started without any up devices, stay with the NO-CARRIER flag set, and thus prevents DAD (Duplicate address detection) from happening, thus letting the IPv6 address flagged as “tentative”. Such addresses cannot be bound to (see RFC 2462), so dnsmasq fails binding to it (for radvd, it detects that "interface XXX is not RUNNING", thus that "interface XXX does not exist, ignoring the interface" (sic)). It seems that this behavior was enhanced somehow with commit [2] by avoiding setting NO-CARRIER on empty bridges, but I couldn't reproduce this behavior on my kernel. Anyway, with the “dummy tap to set MAC address” trick, this wouldn't work. To fix this, the idea is to get the bridge's attached device to be up so that DAD can happen (deactivating DAD altogether is not a good idea, I think). Currently, libvirt creates a dummy TAP device to set the MAC address of the bridge, keeping it down. But even if we set this device up, it is not RUNNING as soon as the tap file descriptor attached to it is closed, thus still preventing DAD. So, we must modify the API a bit, so that we can get the fd, keep the tap device persistent, run the daemons, and close it after DAD has taken place. After that, the bridge will be flagged NO-CARRIER again, but the daemons will be running, even if not happy about the device's state (but we don't really care about the bridge's daemons doing anything when no up interface is connected to it). Other solutions that I envisioned were: * Keeping the *-nic interface up: this would waste an fd for each bridge during all its life. May be acceptable, I don't really know. * Stop using the dummy tap trick, and set the MAC address directly on the bridge: it is possible since quite some time it seems, even if then there is the problem of the bridge not being RUNNING when empty, contrary to what [2] says, so this will need fixing (and this fix only happened in 3.1, so it wouldn't work for 2.6.39) * Using the --interface option of dnsmasq, but I saw somewhere that it's not used by libvirt for backward compatibility. I am not sure this would solve this problem, though, as I don't know how dnsmasq binds itself to it with this option. This is why this patch does what's described earlier. This patch also makes radvd start even if the interface is “missing” (i.e. it is not RUNNING), as it daemonizes before binding to it, and thus sometimes does it after the interface has been brought down by us (by closing the tap fd), and then originally stops. This also makes it stop yelling about it in the logs when the interface is down at a later time. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=1faa4356a3bd89ea11fb92752d897cff3a20ec0e [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=b64b73d7d0c480f75684519c6134e79d50c1b341
-