1. 18 7月, 2019 1 次提交
  2. 17 5月, 2019 1 次提交
    • D
      src: don't statically link code that's already in libvirt.so · e5df4ede
      Daniel P. Berrangé 提交于
      Various binaries are statically linking to libvirt_util.la and
      other intermediate libraries we build. These intermediate libs
      all get built into the main libvirt.so shared library eventually,
      so we can dynamically link to that instead and reduce the on disk
      footprint.
      
      In libvirt-daemon RPM:
      
                  virtlockd: 1.6 MB -> 153 KB
                   virtlogd: 1.6 MB -> 157 KB
           libvirt_iohelper: 937 KB -> 23 KB
      
      In libvirt-daemon-driver-network RPM:
      
       libvirt_leaseshelper: 940 KB -> 26 KB
      
      In libvirt-daemon-driver-storage-core RPM:
      
         libvirt_parthelper: 926 KB -> 21 KB
      
      IOW, about 5.6 MB total space saving in a build done on Fedora 30
      x86_64 architecture.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      e5df4ede
  3. 12 4月, 2019 1 次提交
  4. 02 2月, 2019 1 次提交
    • L
      configure: selectively install a firewalld 'libvirt' zone · 3b71f2e4
      Laine Stump 提交于
      In the past (when both libvirt and firewalld used iptables), if either
      libvirt's rules *OR* firewalld's rules accepted a packet, it would
      be accepted. This was because libvirt and firewalld rules were
      processed during the same kernel hook, and a single ACCEPT result
      would terminate the rule traversal and cause the packet to be
      accepted.
      
      But now firewalld can use nftables for its backend, while libvirt's
      firewall rules are still using iptables; iptables rules are still
      processed, but at a different time during packet processing
      (i.e. during a different hook) than the firewalld nftables rules. The
      result is that a packet must be accepted by *BOTH* the libvirt
      iptables rules *AND* the firewalld nftable rules in order to be
      accepted.
      
      This causes pain because
      
      1) libvirt always adds rules to permit DNS and DHCP (and sometimes
      TFTP) from guests to the host network's bridge interface. But
      libvirt's bridges are in firewalld's "default" zone (which is usually
      the zone called "public"). The public zone allows ssh, but doesn't
      allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the
      DHCP and DNS traffic, the firewalld rules (now processed during a
      different hook) dont, thus guests connected to libvirt's bridges can't
      acquire an IP address from DHCP, nor can they make DNS queries to the
      DNS server libvirt has setup on the host. (This could be solved by
      modifying the default firewalld zone to allow DNS and DHCP, but that
      would open *all* interfaces in the default zone to those services,
      which is most likely not what the host's admin wants.)
      
      2) Even though libvirt adds iptables rules to allow forwarded traffic
      to pass the iptables hook, firewalld's higher level "rich rules" don't
      yet have the ability to configure the acceptance of forwarded traffic
      (traffic that is going somewhere beyond the host), so any traffic that
      needs to be forwarded from guests to the network beyond the host is
      rejected during the nftables hook by the default zone's "default
      reject" policy (which rejects all traffic in the zone not specifically
      allowed by the rules in the zone, whether that traffic is destined to
      be forwarded or locally received by the host).
      
      libvirt can't send "direct" nftables rules (firewalld only supports
      direct/passthrough rules for iptables), so we can't solve this problem
      by just sending explicit nftables rules instead of explicit iptables
      rules (which, if it could be done, would place libvirt's rules in the
      same hook as firewalld's native rules, and thus eliminate the need for
      packets to be accepted by both libvirt's and firewalld's own rules).
      
      However, we can take advantage of a quirk in firewalld zones that have
      a default policy of "accept" (meaning any packet that doesn't match a
      specific rule in the zone will be *accepted*) - this default accept will
      also accept forwarded traffic (not just traffic destined for the host).
      
      Of course we don't want to modify firewalld's default zone in that
      way, because that would affect the filtering of traffic coming into
      the host from other interfaces using that zone. Instead, we will
      create a new zone called "libvirt". The libvirt zone will have a
      default policy of accept so that forwarded traffic can pass and list
      specific services that will be allowed into the host from guests (DNS,
      DHCP, SSH, and TFTP).
      
      But the same default accept policy that fixes forwarded traffic also
      causes *all* traffic from guest to host to be accepted. To close this
      new hole, the libvirt zone can take advantage of a new feature in
      firewalld (currently slated for firewalld-0.7.0) - priorities for rich
      rules - to add a low priority rule that rejects all local traffic (but
      leaves alone all forwarded traffic).
      
      So, our new zone will start with a list of services that are allowed
      (dhcp, dns, tftp, and ssh to start, but configurable via any firewalld
      management application, or direct editing of the zone file in
      /etc/firewalld/zones/libvirt.xml), followed by a low priority
      <reject/> rule (to reject all other traffic from guest to host), and
      finally with a default policy of accept (to allow forwarded traffic).
      
      This patch only creates the zonefile for the new zone, and implements
      a configure.ac option to selectively enable/disable installation of
      the new zone. A separate patch contains the necessary code to actually
      place bridge interfaces in the libvirt zone.
      
      Why do we need a configure option to disable installation of the new
      libvirt zone? It uses a new firewalld attribute that sets the priority
      of a rich rule; this feature first appears in firewalld-0.7.0 (unless
      it has been backported to am earlier firewalld by a downstream
      maintainer). If the file were installed on a system with firewalld
      that didn't support rule priorities, firewalld would log an error
      every time it restarted, causing confusion and lots of extra bug
      reports.
      
      So we add two new configure.ac switches to avoid polluting the system
      logs with this error on systems that don't support rule priorities -
      "--with-firewalld-zone" and "--without-firewalld-zone". A package
      builder can use these to include/exclude the libvirt zone file in the
      installation. If firewalld is enabled (--with-firewalld), the default
      is --with-firewalld-zone, but it can be disabled during configure
      (using --without-firewalld-zone). Targets that are using a firewalld
      version too old to support the rule priority setting in the libvirt
      zone file can simply add --without-firewalld-zone to their configure
      commandline.
      
      These switches only affect whether or not the libvirt zone file is
      *installed* in /usr/lib/firewalld/zones, but have no effect on whether
      or not libvirt looks for a zone called libvirt and tries to use it.
      
      NB: firewalld zones can only be added to the permanent config of
      firewalld, and won't be loaded/enabled until firewalld is restarted,
      so at package install/upgrade time we have to restart firewalld. For
      rpm-based distros, this is done in the libvirt.spec file by calling
      the %firewalld_restart rpm macro, which is a part of the
      firewalld-filesystem package. (For distros that don't use rpm
      packages, the command "firewalld-cmd --reload" will have the same
      effect).
      Signed-off-by: NLaine Stump <laine@laine.org>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      3b71f2e4
  5. 06 3月, 2018 1 次提交