1. 18 Feb, 2021 2 commits
  2. 12 Feb, 2021 1 commit
    • Thomas Haller's avatar
      build: make path to polkit-agent-helper-1 binary configurable · 8f2ca652
      Thomas Haller authored
      Add new configure option to set the path to "polkit-agent-helper-1".
      
      The path cannot be obtained from pkg-config and `pkg-config
      --variable=prefix polkit-agent-1` is not good enough.
      
      On Fedora, the path is "/usr/lib/polkit-1/polkit-agent-helper-1".
      On Debian Buster, the path is "/usr/lib/policykit-1/polkit-agent-helper-1"
      On Debian Sid, the path is "/usr/libexec/polkit-agent-helper-1" (but
      currently it is also symlinked from "/usr/lib/policykit-1/polkit-agent-helper-1".
      
      (cherry picked from commit 801c41a1)
      8f2ca652
  3. 11 Feb, 2021 1 commit
  4. 08 Feb, 2021 1 commit
  5. 26 Jan, 2021 1 commit
    • Roy Marples's avatar
      DHCP: Support dhcpcd-9.x · a2abd15f
      Roy Marples authored and Thomas Haller's avatar Thomas Haller committed
      This locks NM into dhcpcd-9.3.3 as that is the first version to support
      the --noconfigure option. Older versions are no longer supported by NM
      because they do modify the host which is undesirable.
      
      Due to the way dhcpcd-9 uses privilege separation and that it re-parents
      itself to PID 1, the main process cannot be reaped or waited for.
      So we rely on dhcpcd correctly cleaning up after itself.
      A new function nm_dhcp_client_stop_watch_child() has been added
      so that dhcpcd can perform similar cleanup to the equivalent stop call.
      
      As part of this change, the STOP and STOPPED reasons are mapped to
      NM_DHCP_STATE_DONE and PREINIT is mapped to a new state NM_DHCP_STATE_NOOP
      which means NM should just ignore this state.
      
      !668
      a2abd15f
  6. 12 Jan, 2021 1 commit
  7. 07 Dec, 2020 1 commit
  8. 24 Nov, 2020 2 commits
  9. 23 Nov, 2020 2 commits
    • Thomas Haller's avatar
      Revert "dns: change default DNS priority of VPNs to -50" · 034db883
      Thomas Haller authored
      Revert this change. One problem is that none of the current GUIs
      (nm-connection-editor, gnome-control-center, plasma-nm) expose the
      dns-priority option. So, users tend to have their profile value set to
      0. Changing the default means for them not only a change in behavior,
      but its hard to fix via the GUI.
      
      Also, what other call DNS leaks, is Split DNS to some. Both uses make
      sense, but have conflicting goals. The default cannot accommodate both
      at the same time.
      
      Also, with split DNS enabled (dnsmasq, systemd-resolved), the concern
      for DNS leaks is smaller. Imagine:
      
        Wi-Fi profile with ipv4.dns-priority (effectively) 100, domain "example.com".
        VPN profile with ipv4.dns-priority (effectively) 50 and a default route.
      
      That is a common setup that one gets by default (and what probably many
      users have today). In such a case with split DNS enabled, the Wi-Fi's DNS
      server only sees requests for "*.example.com". So, it does not leak
      everything.
      
      Hence, revert this change before 1.28.0 release to the earlier behavior.
      
      This reverts commit af13081b.
      
      !688
      (cherry picked from commit ff71bbdc)
      034db883
    • Thomas Haller's avatar
      Revert "dns: change default DNS priority of VPNs to -50" · ff71bbdc
      Thomas Haller authored
      Revert this change. One problem is that none of the current GUIs
      (nm-connection-editor, gnome-control-center, plasma-nm) expose the
      dns-priority option. So, users tend to have their profile value set to
      0. Changing the default means for them not only a change in behavior,
      but its hard to fix via the GUI.
      
      Also, what other call DNS leaks, is Split DNS to some. Both uses make
      sense, but have conflicting goals. The default cannot accommodate both
      at the same time.
      
      Also, with split DNS enabled (dnsmasq, systemd-resolved), the concern
      for DNS leaks is smaller. Imagine:
      
        Wi-Fi profile with ipv4.dns-priority (effectively) 100, domain "example.com".
        VPN profile with ipv4.dns-priority (effectively) 50 and a default route.
      
      That is a common setup that one gets by default (and what probably many
      users have today). In such a case with split DNS enabled, the Wi-Fi's DNS
      server only sees requests for "*.example.com". So, it does not leak
      everything.
      
      Hence, revert this change before 1.28.0 release to the earlier behavior.
      
      This reverts commit af13081b.
      
      !688
      ff71bbdc
  10. 16 Nov, 2020 1 commit
  11. 20 Oct, 2020 3 commits
  12. 19 Oct, 2020 1 commit
  13. 09 Oct, 2020 3 commits
    • Antonio Cardace's avatar
      NEWS: update · 8764d47a
      Antonio Cardace authored
      
      
      Signed-off-by: Antonio Cardace's avatarAntonio Cardace <acardace@redhat.com>
      8764d47a
    • Beniamino Galvani's avatar
      dns: change default DNS priority of VPNs to -50 · f10e4fe8
      Beniamino Galvani authored
      Change the default DNS priority of VPNs to -50, to avoid leaking
      queries out of full-tunnel VPNs.
      
      This is a change in behavior. In particular:
      
       - when using dns=default (i.e. no split-dns) before this patch both
         VPN and the local name server were added (in this order) to
         resolv.conf; the result was that depending on resolv.conf options
         and resolver implementation, the name servers were tried in a
         certain manner which does not prevent DNS leaks.
         With this change, only the VPN name server is added to resolv.conf.
      
       - When using a split-dns plugin (systemd-resolved or dnsmasq), before
         this patch the full-tunnel VPN would get all queries except those
         ending in a local domain, that would instead be directed to the
         local server.
         After this patch, the VPN gets all queries.
      
      To revert to the old behavior, set the DNS priority to 50 in the
      connection profile.
      
      (cherry picked from commit af13081b)
      f10e4fe8
    • Beniamino Galvani's avatar
      dns: change default DNS priority of VPNs to -50 · af13081b
      Beniamino Galvani authored
      Change the default DNS priority of VPNs to -50, to avoid leaking
      queries out of full-tunnel VPNs.
      
      This is a change in behavior. In particular:
      
       - when using dns=default (i.e. no split-dns) before this patch both
         VPN and the local name server were added (in this order) to
         resolv.conf; the result was that depending on resolv.conf options
         and resolver implementation, the name servers were tried in a
         certain manner which does not prevent DNS leaks.
         With this change, only the VPN name server is added to resolv.conf.
      
       - When using a split-dns plugin (systemd-resolved or dnsmasq), before
         this patch the full-tunnel VPN would get all queries except those
         ending in a local domain, that would instead be directed to the
         local server.
         After this patch, the VPN gets all queries.
      
      To revert to the old behavior, set the DNS priority to 50 in the
      connection profile.
      af13081b
  14. 06 Oct, 2020 1 commit
  15. 05 Oct, 2020 1 commit
  16. 29 Sep, 2020 1 commit
    • Thomas Haller's avatar
      device: allow non-privileged users to call device.GetAppliedConnection() · 549b126a
      Thomas Haller authored
      Compare to the connection's GetSettings() call, which is not protected
      by policykit permissions. It only checks that the requesting user is
      allowed according to "connection.permission".
      
      Previously, device's GetAppliedConnection() requires "network-control"
      permissions. This although it only reads a profile, without modifying
      anything. That seems unnecessary, also because in the common case the
      applied connection is identical to the current settings connection, and
      the latter can be read without special permissions.
      
      Don't require a special policykit permission to read the applied
      connection.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1882380
      549b126a
  17. 18 Sep, 2020 1 commit
  18. 24 Aug, 2020 1 commit
    • Thomas Haller's avatar
      dns: add new "rc-manager=auto" mode · c1f9a0ff
      Thomas Haller authored
      Add a new `main.rc-manager=auto` setting, that favours to use
      systemd-resolved (and not touch "/etc/resolv.conf" but configure
      it via D-Bus), or falls back to `resolvconf`/`netconfig` binaries
      if they are installed and enabled at compile time.
      As final fallback use "symlink", like before.
      
      Note that on Fedora there is no "openresolv" package ([1]). Instead, "systemd"
      package provides "/usr/sbin/resolvconf" as a wrapper for systemd-resolved's
      "resolvectl". On such a system the fallback to resolvconf is always
      wrong, because NetworkManager should either talk to systemd-resolved
      directly or not but never call "/usr/sbin/resolvconf". So, the special handling
      for resolvconf and netconfig is only done if NetworkManager was build with these
      applications explicitly enabled.
      
      Note that SUSE builds NetworkManager with
      
          --with-netconfig=yes
          --with-config-dns-rc-manager-default=netconfig
      
      and the new option won't be used there either. But of course, netconfig
      already does all the right things on SUSE.
      
      [1] https://bugzilla.redhat.com/show_bug.cgi?id=668153
      
      
      
      Suggested-by: Jason A. Donenfeld's avatarJason A. Donenfeld <Jason@zx2c4.com>
      c1f9a0ff
  19. 13 Jul, 2020 4 commits
  20. 28 Jun, 2020 2 commits
  21. 26 Jun, 2020 1 commit
  22. 15 Jun, 2020 3 commits
  23. 03 Jun, 2020 1 commit
  24. 29 May, 2020 2 commits
  25. 15 May, 2020 1 commit
    • Beniamino Galvani's avatar
      device: use the nm-shared firewalld zone in shared mode · 3e2b7235
      Beniamino Galvani authored
      When the interface is in IPv4 or IPv6 shared mode and the user didn't
      specify an explicit zone, use the nm-shared one.
      
      Note that masquerade is still done through iptables direct calls
      because at the moment it is not possible for a firewalld zone to do
      masquerade based on the input interface.
      
      The firewalld zone is needed on systems where firewalld is using the
      nftables backend and the 'iptables' binary uses the iptables API
      (instead of the nftables one). On such systems, even if the traffic is
      allowed in iptables by our direct rules, it can still be dropped in
      nftables by firewalld.
      3e2b7235
  26. 08 May, 2020 1 commit