Even when there's no <secret>-flags key for it in vpn-data.
This is essentially to fix regression in the way openconnect uses the VPN
secrets:
Openconnect auth helper is essentially a web browser that fills in an arbitrary
HTML (or XML) form that's used to get the session cookie. The actual secret the
service needs is the cookie itself.
However, what needs to be remembered includes the form data. What data can be
in the form is installation dependent and can not be known in advance. Thus the
flags for it can't be currently set in the connection. The auth helper is not
capable of setting the flags either, because it can only return secrets.
Prior to 1424f249e we treated vpn.secrets without the flags as system secrets
and store them in the connection. Since that commit we just filter them away,
which broke user configurations.
This restores the behavior or treating everyting in vpn.secrets as secrets and
falling back to system secrets.
Another way would be to find a way to flag the secrets, perhaps by
extending the auth helper protocol to be able to store non-secret
properties too.
https://bugzilla.gnome.org/show_bug.cgi?id=768737
Even if the 'ad_actor_system' option is only valid for the 802.3ad
mode, the sysfs file is always present and has a default value of
''. But in 802.3ad mode the default value is
'00:00:00:00:00:00'. Return the correct value in
nm_setting_bond_get_option_default().
Furthermore, writing a empty string to the file will generate an
error, don't do it.
We print an error when the write of a bond options fails as this is
considered an effect of a wrong configuration (or a bug in the checks
done by NM) that the user should notice. But not all options are
supported in all bonding modes and so we ignore some unsupported
options for the current mode to avoid populating logs with useless
errors.
Improve the code there by using a more generic approach and
synchronize the mode/option compatibility table with kernel (file
drivers/net/bonding/bond_options.c).
https://bugzilla.gnome.org/show_bug.cgi?id=767776https://bugzilla.redhat.com/show_bug.cgi?id=1352131
Since commit 7d1709d7f6 ("device: check may_fail when progressing to
IP_CHECK") NM correctly checks the may-fail properties to decide
whether a connection must fail after the completion of IP
configuration. But for ipv4.method=disabled and ipv6.method=ignore the
IP configuration is always considered failed and thus setting
may-fail=no results in a connection that can never succeed.
To prevent such wrong configuration, force may-fail to TRUE for those
methods during connection normalization.
https://bugzilla.redhat.com/show_bug.cgi?id=1334884
@buf_len is always initialized when @buf_arr is set but gcc fails to
recognize it:
../libnm-core/nm-keyfile-reader.c: In function 'mac_address_parser':
../libnm-core/nm-keyfile-reader.c:654:36: error: 'buf_len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
tmp_string = nm_utils_hwaddr_ntoa (buf_arr, buf_len);
Fixes: 8eed67122c
For the per-connection settings "ethernet.cloned-mac-address"
and "wifi.cloned-mac-address", and for the per-device setting
"wifi.scan-rand-mac-address", we may generate MAC addresses using
either the "random" or "stable" algorithm.
Add new properties "generate-mac-address-mask" that allow to configure
which bits of the MAC address will be scrambled.
By default, the "random" and "stable" algorithms scamble all bits
of the MAC address, including the OUI part and generate a locally-
administered, unicast address.
By specifying a MAC address mask, we can now configure to perserve
parts of the current MAC address of the device. For example, setting
"FF:FF:FF:00:00:00" will preserve the first 3 octects of the current
MAC address.
One can also explicitly specify a MAC address to use instead of the
current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00"
sets the OUI part of the MAC address to "68:F7:28" while scrambling
the last 3 octects.
Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble
all bits of the MAC address, except clearing the second-least
significant bit. Thus, creating a burned-in address, globally
administered.
One can also supply a list of MAC addresses like
"FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which
case a MAC address is choosen randomly.
To fully scamble the MAC address one can configure
"02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00".
which also randomly creates either a locally or globally administered
address.
With this, the following macchanger options can be implemented:
`macchanger --random`
This is the default if no mask is configured.
-> ""
while is the same as:
-> "00:00:00:00:00:00"
-> "02:00:00:00:00:00 02:00:00:00:00:00"
`macchanger --random --bia`
-> "02:00:00:00:00:00 00:00:00:00:00:00"
`macchanger --ending`
This option cannot be fully implemented, because macchanger
uses the current MAC address but also implies --bia.
-> "FF:FF:FF:00:00:00"
This would yields the same result only if the current MAC address
is already a burned-in address too. Otherwise, it has not the same
effect as --ending.
-> "FF:FF:FF:00:00:00 <MAC_ADDR>"
Alternatively, instead of using the current MAC address,
spell the OUI part out. But again, that is not really the
same as macchanger does because you explictly have to name
the OUI part to use.
`machanger --another`
`machanger --another_any`
-> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..."
"$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address"
settings. Instead of specifying an explicit MAC address, the additional
special values "permanent", "preserve", "random", "random-bia", "stable" and
"stable-bia" are supported.
"permanent" means to use the permanent hardware address. Previously that
was the default if no explict cloned-mac-address was set. The default is
thus still "permanent", but it can be overwritten by global
configuration.
"preserve" means not to configure the MAC address when activating the
device. That was actually the default behavior before introducing MAC
address handling with commit 1b49f941a6.
"random" and "random-bia" use a randomized MAC address for each
connection. "stable" and "stable-bia" use a generated, stable
address based on some token. The "bia" suffix says to generate a
burned-in address. The stable method by default uses as token the
connection UUID, but the token can be explicitly choosen via
"stable:<TOKEN>" and "stable-bia:<TOKEN>".
On a D-Bus level, the "cloned-mac-address" is a bytestring and thus
cannot express the new forms. It is replaced by the new
"assigned-mac-address" field. For the GObject property, libnm's API,
nmcli, keyfile, etc. the old name "cloned-mac-address" is still used.
Deprecating the old field seems more complicated then just extending
the use of the existing "cloned-mac-address" field, although the name
doesn't match well with the extended meaning.
There is some overlap with the "wifi.mac-address-randomization" setting.
https://bugzilla.gnome.org/show_bug.cgi?id=705545https://bugzilla.gnome.org/show_bug.cgi?id=708820https://bugzilla.gnome.org/show_bug.cgi?id=758301
_nm_utils_hwaddr_to_dbus() would serialize invalid hardware addresses
as "'cloned-mac-address': <@ay []>".
An empty array is treated the same as no hardware address set,
so we should not serialize it in the first place.
This is a change in behavior on how the connection is exported
on D-Bus, but it should not have any bad consequences.
We need this as we later want to deprecate the 'cloned-mac-address'
D-Bus field and overwrite it via a 'assigned-mac-address' field.
In this case, the "<@ay []>" is interfering. While it could be worked
around by treating an empty MAC address as "unset", fix it instead
and just not serialize it.
When comparing settings, nm_setting_compare() performs a complicated
logic, which basically serializes each GObject property to a GVariant
for the D-Bus representation.
That is wrong for example for ipv4.addresses, which don't contain
address labels. That is, the GObject property is called "addresses",
but the D-Bus field "addresses" cannot encode every information
and thus comparison fails. Instead, it would have to look into
"address-data".
Traditionally, we have virtual functions like compare_property() per
NMSetting to do the comparison. That comparison is based on the GObject
properties. I think that is wrong, because we should have a generic
concept of what a property is, independent from GObject properties.
With libnm, we added NMSettingProperty, which indeed is such an
GObject independent representation to define properties.
However, it is not used thoroughly, instead compare_property() is a hack
of special cases, overloads from NMSettingProperty, overloads of
compare_property(), and default behavior based on GParamSpec.
This should be cleaned up.
For now, just hack it by handle the properties with the problems
explicitly.
The Network_ID for generating RFC 7217 stable privacy IPv6 addresses
is by default the UUID of the connection.
Alternatively, prefer "connection.stable-id" as Network_ID to generate
the stable addresses. This allows to configure a set of connections that
all use the same Network_ID for generating stable addresses.
Note that the stable-id and the UUID do no overlap, that is two
connections
[connection]
uuid=uuid1
stable-id=
and
[connection]
uuid=uuid2
stable-id=uuid1
generate distinct addresses.
This new property be used as token to generate stable-ids instead
of the connection's UUID.
Later, this will be used by ipv6.addr-gen-mode=stable-privacy,
ethernet.cloned-mac-address=stable, and wifi.cloned-mac-address=stable
setting. Those generate stable addresses based on the connection's
UUID, but allow to use the stable-id instead.
This allows multiple connections to generate the same addresses
-- on the same machine, because in the above cases a machine
dependant key is also hashed.
The "shared" directory contains files that are possibly used by all components
of NetworkManager repository.
Some of these files are even copied as-is to other projects (VPN plugins, nm-applet)
and used there without modification. Move those files to a separate directory.
By moving them to a common directory, it is clearer that they belong
together. Also, you can easier compare the copied versions to their
original via
$ diff -r ./shared/nm-utils/ /path/to/nm-vpn-plugin/shared/nm-utils/
Let VPN plugins return a virtual function table to extend
the API while bypassing libnm. This allows to add and use
new functionality to VPN plugins without updating libnm.
The actual definitions are in a header-only file
"nm-vpn-editor-plugin-call.h", which can be copied to the
caller/plugin.
The NMVpnPluginInfo is essentially the .name file, that is, a
configuration file about the plugin itself. Via NMVpnPluginInfo
instance, the NMVpnEditorPlugin can be created.
Usually, one would create a NMVpnPluginInfo (that is, reading the
.name file) and then create a NMVpnEditorPlugin instance from there.
In this case, usually the editor-plugin is owned by the plugin-info
instance (although the API allows for creating the editor-plugin
independently).
Now, pass the NMVpnPluginInfo to the editor-plugin too.
This is useful, because then the editor-plugin can look at the .name
file.
The .name file is not user configuration. Instead it is configuration
about the plugin itself. Although the .name file is part of the plugin
build artefacts, it is useful to allow the plugin to access the .name
file. The reason is, that this can allow the user to easily change a
configuration knob of the plugin without requiring to patch or the
plugin.
Refactor code to add function _list_find_by_service(), which will be used in the
next commit.
A notable change is that we now search also through the aliases
together with the service-name.
That makes a difference, if one plugin privdes an "alias" which another
plugin provides as "service". Due to that change, we would also find the
aliased plugin first.
In practice it shouldn't matter, because different plugins are
not supposed to provide identical services.
Commit bdd0e7fec0 which added symbol
nm_setting_ip_config_get_dns_priority to libnm_1_4_0 was backported
to nm-1-2 in commit ad1cdcf6571da23e3197b09f1b4b14d23b8899d1.
Add the backported symbol to master to allow seemless upgrading
from 1.2.4 to 1.4.0.
A failure to g_return*() by default prints a g_critical() with stringifing the
condition. Add a macro NMTST_G_RETURN_MSG() that reproduces that line to more
accurately match the failure message.
Add new Reload D-Bus command to reload NetworkManager configuration.
For now, this is like sending SIGHUP to the process. There are several
advantages here:
- it is guarded via PolicyKit authentication while signals
can only be sent by root.
- the user can wait for the reload to be complete instead of sending
an asynchronous signal. For now, we operation completes after
nm_config_reload() returns, but later we could delay the response
further until specific parts are fully reloaded.
- SIGHUP reloads everything including re-reading configuration from
disk while SIGUSR1 reloads just certain parts such as writing out DNS
configuration anew.
Now, the Reload command has a flags argument which is more granular
in selecting parts which are to be reloaded. For example, via
signals the user can:
1) send SIGUSR1: this writes out the DNS configuration to
resolv.conf and possibly reloads other parts without
re-reading configuration and without restarting the DNS plugin.
2) send SIGHUP: this reloads configuration from disk,
writes out resolv.conf and restarts the DNS plugin.
There is no way, to only restart the DNS plugin without also reloading
everything else.
NMSettingTeam implements a custom compare_property() method in order
to perform a relaxed matching on team configurations when it is
necessary to assume a connection. However, the method is called also
when the core needs to check if a connection has changed before an
update. In that case it is better to use the default string comparison
on the property, otherwise the second of these commands would not have
effect:
$ nmcli connection modify team0 team.config ''
$ nmcli connection modify team0 team.config '{ }'
because compare_property() returns TRUE. Use the @flags argument to
distinguish the two cases.
Fixes: 82f8a54854
This sorts the entries of the [vpn] section alphabetically.
The sorting order doesn't really matter, but having a defined,
stable way to export a connection is preferred. Also, it looks
better when looking at the keyfile with an editor.
No need to require the caller to initialize the optional out-argument.
Otherwise we get:
(nm-connection-editor:2471): libnm-CRITICAL **: nm_utils_file_is_private_key: assertion 'out_encrypted == NULL || *out_encrypted == FALSE' failed
https://bugzilla.gnome.org/show_bug.cgi?id=763578
Fixes: 1c4f41c610
This is required to add objects in the "Types and Values" section and
in the API index. Later, we may want to add useful content in those
empty comments.
<gmodule.h> is implicitly included by <gio/gio.h> which is available
everywhere. For that reason, we would not have to include this header
at all. However, it is recommended to explicitly include <gmodule.h>
where needed.
So, include it where needed -- if <gio/gio.h> wouldn't be there --
and drop it from where it is not needed.
Closing the library will interfere badly as the glib types cannot be
unregistered. We must leak the library handle.
Switch to dlopen() instead of g_module_open(), because the former
supports RTLD_NOLOAD. This is useful for two reasons:
- checking the file prior loading only makes any sense when
dlopen() would actually load a file anew.
- if the library was loaded before, we want to return the handle.
On the other hand, if the library was not loaded, we leak the
handle.
Thereby, refactor the code from if-else blocks to return-early, because
the function nicely does individual steps and if one fails just error
out.
g_object_get_data() and g_object_get_qdata() end up to be identical,
except that g_object_get_data() also requires to intern the string
on every lookup (which involves a hash lookup and locking).
Having a gateway defined when never-default=yes causes troubles in
connection matching and anyway makes no sense.
If the combination is found, remove the gateway during the
normalization phase.
https://bugzilla.redhat.com/show_bug.cgi?id=1313091
libnm-core/nm-vpn-plugin-info.c: In function ‘nm_vpn_plugin_info_get_auth_dialog’:
shared/gsystem-local-alloc.h:53:46: error: ‘prog_basename’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
Fixes: a3f94f451b
