If a device's "managed" configuration is changed persistently (stored to
NM-intern), it needs to be undone in a rollback.
(cherry picked from commit 2fbaca1cbc)
We need to wait for it to finish so we can show error messages, if any.
Also, if we don't do it, sometimes the `d set eth0 managed ...`
operation fails with the following message in the daemon's log: "Unable
to determine UID of the request". This is because the client's process
is terminated before the daemon can check the permissions, as it needs
to check the uid and gid from the client's process.
(cherry picked from commit 7ee50b687a)
Allow to manage or unmanage a device persisting across reboots.
If --permanent is not specified, only the runtime managed state is
changed, preserving the previous behavior. The --permanent-only
option allows to edit only the persistent value, without touching
the runtime value.
Also add the values up/down. Up means managed=yes and set device's
administrative state UP. Down means managed=no and admin state DOWN.
Add the value 'reset' too. It reverts managed runtime status to default
behaviour. When used with `--permanent` flag, the persisted managed
settings is cleared.
Co-authored-by: Rahul Rajesh <rajeshrah22@gmail.com>
(cherry picked from commit d2f98a1669)
Devices like veth without a permanent MAC address cannot be matched by
MAC. If using the BY_MAC flag in SetManaged(), the changes are not
effective for such kind of devices.
Add a BY_NAME flag, in addition to the BY_MAC one. If the client sets
one of them, it means to force this mode of matching. If none is
selected, the daemon will choose how to match, preferring matching by
MAC when possible, and by ifname when not possible.
(cherry picked from commit 7c8f343f2c)
Control it with a new NM_DEVICE_MANAGED_SET_ADMIN_STATE flag.
This flag will make that, at the same time that the device is moved to
managed/unmanaged, it's admin state is set to up/down. Many users want
to have a way to have their devices in a DOWN admin state when they are
not using them. Because of the complex activation process, NM wants to
have its devices in UP state all the time. However, it is not a problem
to have it DOWN if we are not managing it.
(cherry picked from commit b9725dab73)
Previous commits added the capability to persist to disk the value of
'managed' received via the D-Bus API. Users might need to clear the
previous content, thus reseting it to its default.
Although this is specially useful for the PERMANENT flag, we need to be
consistent and reset the runtime state too.
(cherry picked from commit f346fcf977)
If the NM_DEVICE_MANAGED_FLAGS_PERMANENT flag is used, the value will be
stored to disk, to the NetworkManager-intern.conf file, in a [device-*]
section.
To modify the runtime value, the NM_DEVICE_MANAGED_FLAGS_RUNTIME must be
passed. This allows to control independently whether to modify only one
or both.
(cherry picked from commit ec1522fa8c)
To support setting devices as managed or unmanaged via D-Bus API in a
permanent way, we need a way to store this configuration on disk. Before
this commit, only config files manually edited allowed it. Following
commits will make use of the new functions to store [device-*] sections
into NetworkManager-intern.conf depending on D-Bus method invocations.
(cherry picked from commit 0a1503f052)
Now it is possible to have [.intern.device-*] sections in
NetworkManager-intern.conf. Take them into account when parsing the
configuration keyfiles.
(cherry picked from commit 47c1b04f9e)
The 'Managed' property only sets the managed state in runtime, but it is
not possible to persist it to disk. Add a SetManaged method that will be
able to persist it to disk. In this commit, it just modify the runtime
state, so it actually only does the same than setting the property.
Storing to disk will be added in next commits.
(cherry picked from commit 9ff530c322)
Added support for the following properties in connection profile:
id (VNI), remote IPv4/IPv6, ttl, tos, df, destination port.
See IP-LINK(8) manual page with command `man 8 ip-link` for more details
on the properties. See also previous commit for nm supported attributes.
id and remote are mandatory attributes:
```
$ nmcli connection add type geneve save no
Error: 'id' argument is required.
$ nmcli connection add type geneve id 42 save no
Error: 'remote' argument is required.
```
(cherry picked from commit 2aaf88375e)
GENEVE (Generic Network Virtualization Encapsulation) is a network
tunneling protocol that provides a flexible encapsulation format for
overlay networks. It uses UDP as the transport protocol and supports
variable-length metadata in the tunnel header.
This patch adds GENEVE tunnel to NM's platform layer:
- Add platform API functions (nm_platform_link_geneve_add,
nm_platform_link_get_lnk_geneve)
- Netlink message parsing for the following attributes:
* IFLA_GENEVE_ID - VNI (Virtual Network Identifier)
IPv4 and IPv6 remote
* IFLA_GENEVE_REMOTE
* IFLA_GENEVE_REMOTE6
TTL, TOS, and DF flags
* IFLA_GENEVE_TTL
* IFLA_GENEVE_TOS
* IFLA_GENEVE_DF
UDP destination port
* IFLA_GENEVE_PORT
- Add test cases for GENEVE tunnel creation and detection with two test
modes covering IPv4 and IPv6.
The implementation tries to follow the same patterns as other tunnel
types (GRE, VXLAN, etc.) and integrates with the existing platform
abstraction layer.
(cherry picked from commit 29c8bbe21a)
In kernel, the onlink flag (RTNH_F_ONLINK) is associated with each
nexthop (rtnh_flags) rather than the route as a whole. NM previously
stored it only per-route in NMPlatformIPRoute.r_rtm_flags, which meant
that two nexthops only differing with the onlink flag were combined
as one entry in the platform cache.
Fix this by tracking the onlink flag per-nexthop.
Resolves: https://issues.redhat.com/browse/NMT-1486
(cherry picked from commit d564a0c3f9)
`argument` is not const, but `tmp` is. We use `tmp`
for reading arguments one by one, but we cannot add
a null byte to separate the key and value if it is const.
Make it non-const, so that `val[0] = '\0';` does not fail.
We write into the buffer returned by nm_strsplit_set_full(), even
though it is returned as `const char**`. The function description
claims this is fine:
> * It is however safe and allowed to modify the individual strings in-place,
> * like "g_strstrip((char *) iter[0])".
Remove the const qualifier via cast so that it does not raise errors.
We reallocate this value in the function, which is necessary
because we write into it, and the input is const.
Move the allocation into a local variable instead of overwriting
the input pointer, because we are also pointing to it via
`char* s`, which is not const.
`subsystem_full` is const, so `s` needs to be const too.
Reorder the NULL-byte write so that we are not writing
into a const char* (the underlying memory is the same).
NetworkManager is failing to build on Rawhide with the following errors:
../src/libnm-systemd-shared/src/basic/string-util.h:33:16: error: return discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
33 | return strstr(haystack, needle);
| ^~~~~~
In file included from ../src/libnm-systemd-shared/src/basic/fd-util.c:30:
../src/libnm-systemd-shared/src/basic/sort-util.h: In function ‘bsearch_safe’:
../src/libnm-systemd-shared/src/basic/sort-util.h:34:16: error: return discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
34 | return bsearch(key, base, nmemb, size, compar);
| ^~~~~~~
This is fixed in systemd by commit 0bac1ed2422f15308414dd1e9d09812a966b0348:
> Latest glibc uses _Generic to have strstr() and other functions return
> const char* or char* based on whether the input is a const char* or a
> char*. This causes build failures as we previously always expected a char*.
>
> Let's fix the compilation failures and add our own macros similar to glibc's
> to have string functions that return a mutable or const pointer depending on
> the input.
Selectively backport the changes we need to fix building.
The previous check was based only on the presence of a non-NULL
"existing_secrets" GVariant. That GVariant is created via:
nm_connection_to_dbus(nm_settings_connection_get_connection(self),
NM_CONNECTION_SERIALIZE_WITH_SECRETS_SYSTEM_OWNED)
The function returns a GVariant containing a first-level dictionary
for each setting, even for those that doesn't contain any secrets. As
a result, the check was requiring the system.modify permission even if
there weren't any cached secrets to send to the agent.
Fix the check to actually check for the presence of any secrets in the
cached dictionary. Some connection types have a third-level
dictionary that can be empty, for example VPNs have vpn.secrets.
(cherry picked from commit 024360bffa)
The "modify.system" polkit permission allows a user to modify settings
for connection profiles that belong to all users.
For this reason, when an agent returns system secrets (i.e. secrets
that are going to be stored to disk), NetworkManager checks that the
agent has the modify.system permission.
If a secret has the AGENT_OWNED flag, it's stored in the agent
itself. If the secret has the NOT_SAVED flag, it will be asked to
users at the beginning of every connection attempt.
In both those cases the profile is not modified and there is no need
for the modify.system permission. Fix the check to also consider the
NOT_SAVED flag.
(cherry picked from commit db0825a110)
Properties that define a .to_dbus_function() as a D-Bus override, need
to return early if the flags only ask to serialize secrets.
Fixes: 7fb23b0a62 ('libnm: add NMIPRoutingRule API')
(cherry picked from commit eff8330b57)
Add a build option to allow installing a Polkit rule that will grant
permissions for admin users without asking for their password if they're
in a local console.
This shouldn't be encouraged, though. It's common practice that admin
users has to introduce their password to make system-wide changes. The
standard polkit policy, without this rule, is auth_admin_keep. This
policy will ask for the password once and won't ask for it again for
~5 minutes, so it is not too unconvenient.
Different distros use different group names for users with admin rights,
typically 'sudo' or 'wheel'. The build option allows to define the
desired group, or to leave it empty to not install the rule.
However, until the previous commit it was allowed that local users (even
non-admin) could do system-wide changes without introducing a password.
This option allows to maintain the same behavior for admin users,
keeping backwards compatibility so we avoid breaking existing scripts,
for example. We cannot achieve the same for non-admin users because
allowing them to create system-wide connection causes security
vulnerabilities that cannot be fixed in any other way.
`use_carrier` is removed from kernel since 6.18 [1], and returns
the following error if set to 0:
> option obsolete, use_carrier cannot be disabled
This causes a failure of test-link-linux, so let's set it to 1.
[1] https://lore.kernel.org/all/2029487.1756512517@famine/
(cherry picked from commit d40e88fd02)
The formula is wrong for channels above 144 because the layout of the
80MHz channels is not regular. Use a lookup table.
Fixes: 7bb5961779 ('supplicant: honor the 'wifi.channel-width' property in AP mode')
(cherry picked from commit 5763b9b4de)
On a i686 machine the build fails with:
../src/nm-cloud-setup/main.c: In function ‘_oci_new_vlan_dev’:
../src/nm-cloud-setup/main.c:800:47: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘gssize’ {aka ‘int’} [-Werror=format=]
800 | macvlan_name = g_strdup_printf("macvlan%ld", config_data->iface_idx);
| ~~^ ~~~~~~~~~~~~~~~~~~~~~~
| | |
| long int gssize {aka int}
| %d
../src/nm-cloud-setup/main.c:801:42: error: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘gssize’ {aka ‘int’} [-Werror=format=]
801 | connection_id = g_strdup_printf("%s%ld", connection_type, config_data->iface_idx);
| ~~^ ~~~~~~~~~~~~~~~~~~~~~~
| | |
| long int gssize {aka int}
| %d
Fixes: 68d7e17737 ('Reapply "cloud-setup: create VLANs for multiple VNICs on OCI"')
(cherry picked from commit 748be9a3e7)
Previously, if NM_VERSION_MIN_REQUIRED was not defined, it defaulted to
NM_VERSION. As a consequence, if NM_VERSION_MAX_ALLOWED was defined we
got a compilation error because MAX_ALLOWED < MIN_REQUIRED.
MAX_ALLOWED is used to get compilation warnings if you unintentionally
use a libnm's symbol introduced in a newer version. MIN_REQUIRED is used
to get rid of warnings about symbol deprecations.
Libnm users may want to use MAX_ALLOWED alone, because using a too new
symbol would fail to compile with older libnm. But they might want to
get deprecation warnings as soon as possible, so they want to leave
MIN_REQUIRED empty.
(cherry picked from commit f849163e82)
After the changes in release.sh in previous commits, during development
the value of NM_VERSION will always be the next version, not the latest
released one. As a consequence, we don't need to set MICRO+1 in
NM_API_VERSION, which was a temporary workaround.
(cherry picked from commit 36275bc51c)
After the previous commits, release.sh bumps the version after tagging
the release, and not before. Therefore, it expects that the version is
already the next one when doing the release.
Manually bump the version this time so release.sh sees the right value
the next time it's executed after these changes.
(cherry picked from commit c0fe80ff87)
Fix typo freedestkop -> freedesktop.
Removed unused argument of check_news (additionally, it was incorrectly
using @ instead of $).
Fixed incorrect use of `$? = 0` that was always successful.
(cherry picked from commit 9a3462af99)
After tagging a release, create a commit bumping to the next version.
This effectively ends the change in the logic initiated in the previous
commit, from "bump version, then release" to "release, then bump
version".
The purpose of this is to have the right version set in nm_version.h and
nm_version_macros.h between two releases. Without this change, when we
introduced a new symbol, thus using the NM_AVAILABLE_IN_1_XX annotations,
we got compilation warnings until we did the next release (making the CI
to be red when configured the compilation to fail on warnings).
(cherry picked from commit 5666407f15)
Don't bump the version before tagging the release. Instead, assume that
it's already correctly set. This is in preparation for the next commit
where we will bump the version after the release, not before.
But don't assume that in the case of rc1 and major releases. For rc1 we
switch from devel releases to RC releases, and in major we switch from
RC releases to stable releases. For example, when we are going to
release 1.58-rc1, the current version will be 1.57.X-dev, so we need to
bump to 1.58-rc1. When we're going to release 1.58.0, the current
version will be 1.58-rcX, so we need to bump to 1.58.0.
(cherry picked from commit 3a3a8ea59d)
