"string" is leaked in the error case. But in practice, this cannot
happen because nm_bridge_vlan_to_str() cannot fail.
While at it, replace GString by NMStrBuf.
Thanks Coverity:
Error: RESOURCE_LEAK (CWE-772):
NetworkManager-1.31.3/src/core/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:1565: alloc_fn: Storage is returned from allocation function "g_string_new".
NetworkManager-1.31.3/src/core/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:1565: var_assign: Assigning: "string" = storage returned from "g_string_new("")".
NetworkManager-1.31.3/src/core/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c:1572: leaked_storage: Variable "string" going out of scope leaks the storage it points to.
# 1570| vlan_str = nm_bridge_vlan_to_str(vlan, error);
# 1571| if (!vlan_str)
# 1572|-> return FALSE;
# 1573| if (string->len > 0)
# 1574| g_string_append(string, ",");
It's still not a very good name, but it seems better then
NMUtilsShareRules.
Currently, NMFirewallConfig is mostly about masquerading for shared
mode. But in practice, it's a piece of configuration for something to
configure in the firewall (the NAT and filter rules).
When we configure iptables rules, we really do two independent
steps: enable masquerading and do some filtering.
As such, introduce a helper method _share_iptables_set_masquerade() for
the masquerading part.
nm_utils_share_rules_apply() is at the moment a bit odd, because
of the order in which we add/remove the rule. This will get better next.
Previously, NMUtilsShareRules basically was tracking a list of command
line arguments, and during apply(), it would spawn the (iptables)
processes.
But in practice, this list was always pre-determined by a few
parameters, the interface name and the subnet. Instead of keeping the
list of arguments, only keep those few parameters. And generate the list
of arguments only for the short time when we need them.
The difference is that we will want to support nftables too. Later,
we can just generate a different list of commands, but there is no
need to keep this list around.
nm_act_request_set_shared() already calls nm_utils_share_rules_apply().
Calling it twice, is pretty bad because during deactivate we will only
remove one of each duplicate rule.
Fixes: 701654b930 ('core: refactor tracking of shared-rules to use NMUtilsShareRules')
Networks offering WPA2 and WPA3/SAE at the same time are in WPA3 hybrid
mode. In this case the PSK passphrase rules that apply need to be the
WPA2 rules, so we shouldn't use "sae" as key-mgmt. Also our wifi card
might not support SAE and we want to make sure WPA2 eventually gets used
in that case.
So use "wpa-psk" as key-mgmt method in case an AP is in WPA3 hybrid
mode.
There can also be APs which don't do wpa-psk, but do support
wpa-psk-sha256, so we should match all AKM suites the AP offers to
determine the security type we want to assign it.
According to [1], the only suitable FT cipher suite for WPA3 Enterprise
192-bit mode is "FT over 802.1X, SHA-384", so enable that in case of
key-mgmt is WPA-EAP-SUITE-B-192 to support FT in that case too.
[1] https://mrncciew.com/2020/08/17/wpa3-enterprise/
As mentioned in the wpa_supplicant reference config, when setting PMF to
required with WPA2 (personal or enterprise) authentication, we want to
only enable SHA256 and upwards as HMAC. So enforce that by not passing
WPA-PSK and WPA-EAP to the config in case pmf is set to REQUIRED.
When using modern WPA3 encryption like owe, sae or wpa-eap-suite-b-192
without fallbacks (so not WPA3+WPA2), protected management frames are
required to be enabled by the specification.
For wpa-eap-suite-b-192 we already do this and force PMF to REQUIRED, we
should also do it for OWE and SAE.
Refactor the generation of the key_mgmt option of the wpa_supplicant
config we generate. The goal of this is to lay out all the cases we
support more obviously and to make it a bit clearer that our key-mgmt
property of NMSettingsWirelessSecurity is not the same as the "key_mgmt"
config we set in wpa_supplicant.
We will add a general "firewall-manager", so rename the firewalld related
file. This commit only renames the file. The next commit will change the
symbol naming.
"nm-device.c" is huge, and it does complicated things like handling the
state of the device and IP configuration.
It also contains simpler, individual functions, like converting enums to
strings. Let's move those trivial functions to a new module, so that the
remaining part is smaller.
"nm-device-utils.[ch]" should only contain simpler functions that have
no complex behavior or state.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/840
- Mark NMPPPOps variable as const. It really must not be modified.
- We cache the loaded symbols in a global variable. While this code
is not used in a multi threaded situation, I think we should not
add code that uses global variables that is not thread safe.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/837
Active-connections in the async_op_lst are not guaranteed to have a
settings-connection. In particular, the settings-connection for an
AddAndActivate() AC is set only after the authorization succeeds. Use
the non-asserting variant of the function to fix the following
failure:
nm_active_connection_get_settings_connection: assertion 'sett_conn' failed
1 _g_log_abort()
2 g_logv()
3 g_log()
4 _nm_g_return_if_fail_warning.constprop.14()
5 nm_active_connection_get_settings_connection()
6 active_connection_find()
7 _get_activatable_connections_filter()
8 nm_settings_get_connections_clone()
9 nm_manager_get_activatable_connections()
10 auto_activate_device_cb()
11 g_idle_dispatch()
12 g_main_context_dispatch()
13 g_main_context_iterate.isra.21()
14 g_main_loop_run()
15 main()
Fixes: 33b9fa3a3c ('manager: Keep volatile/external connections while referenced by async_op_lst')
https://bugzilla.redhat.com/show_bug.cgi?id=1933719https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/834
If the configuration contains dns=none and resolv.conf is updated
through a dispatcher script, currently there is no way to tell NM that
the content of resolv.conf changed, so that it can restart a hostname
resolution.
Use SIGUSR1 (and SIGHUP) for that.
wpa-eap-suite-b-192 key-mgmt method uses special values for "pairwise"
and "group" ciphers, we can also handle that a few lines underneath
where those are set to make this a bit easier to read.
We currently set the supplicants PMF config (ieee80211w) inside an if
block that tries to detect whether WPA is used. That if-block doesn't
include the "wpa-eap-suite-b-192" case because we want special
"pairwise" and "group" handling for wpa-eap-suite-b-192. This means
we're currently missing to enable PMF in the "wpa-eap-suite-b-192" case,
even though it's set to REQUIRED.
Fix it by moving the "pairwise" and "group" special-casing down a bit so
we can include "wpa-eap-suite-b-192" in the "Only WPA-specific things
when using WPA" check, that will make sure ieee80211w gets set in the
wpa-eap-suite-b-192 case.
We only set the "ieee80211w" option in the wpa_supplicant config in case
we're using WPA (see the if-block underneath), otherwise the value of
"pmf" is completely ignored. That means the override here (in case WPA
isn't used) isn't getting applied anyway, so just remove it.
It looks a bit weird on the first glance that we do nothing when
NM_SETTING_WIRELESS_SECURITY_PMF_OPTIONAL is used. The reason for this
is that we already intialize the global option "pmf" of wpa_supplicant
to "1" (optional), so add a brief comment about that here.
ResolveAddress is a simple D-Bus API. One might think that it does not
require much logic, and we would just make the D-Bus call directly.
However, we want to ensure that we always sent our latest DNS
configuration to systemd-resolved first, before making any D-Bus request
to resolve a name.
Also, as we D-Bus activate the service and watch the name owner, we
want to handle that. If a user resolves a name while we are still D-Bus
activating, then we need to queue the request.
This adds some complexity in the implementation. But the benefit is that
the API becomes simple from the user's point of view. The queuing and
avoiding race conditions is handled internally.
The implementation does not use standard glib patterns with GAsyncResult
GTask and GCancellable. I find implementing them correctly is more
effort and leads to a less nice API. That might be fine for public API,
which should follow glib style. But this is entirely internal, and
returning a NMDnsSystemdResolvedResolveHandle that allows cancellation
seems more convenient to me.
As we already track the current name owner, it seems wrong to make
requests to the well-known name. It theoretically opens a race
where we would talk to the wrong systemd-resolved instance.
So far, we didn't care and it didn't make much of a difference.
Still, let's talk to the process that we expect.
For infiniband, request_broadcast is automatically (and always) enabled.
Otherwise, we usually don't enable it, and (unlike systemd-networkd),
there is currently no configuration option to enable it.
Still honor the new udev property that can indicate to enable the flag
per device.
See-also: https://github.com/systemd/systemd/pull/ ### 19346
The DHCP client has potentially a large number of options,
including boolean options (flags). It is cumbersome to implement
them one by one. Instead, make more prominent use of NMDhcpClientFlags.
