Comparing @secrets_keys indicates to coverity that it might be NULL.
Below, we access @secrets_keys without check, and coverity doesn't realize
that this cannot crash, because secrets_keys_n would be zero too.
Anyway, this way we safe the sorting, in case we only have
one element.
Kernel doesn't support it for IPv6.
This is especially useful, if you combine static routes
with DHCP. In that case, you might want to get the device-route
to the gateway automatically, but add a static-route for it.
Currently the ifcfg-rh plugin doesn't explicitly store the connection
type for team slaves and is only able to read back ethernet and vlan
connections.
Leave this unchanged for ethernet and vlan slaves, but store the TYPE
variable for other connection types (Wi-Fi and Infiniband) so that we
can properly determine their type when the connection is read.
The number of authentication retires is useful also for passwords aside
802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has
a retry counter and uses a hard-coded value of 3.
Move the setting, so that it can be used in general. Although it is still
not implemented for other settings.
This is an API and ABI break.
Since commit 4a6fd0e83e (device: honor the
connection.autoconnect-retries for 802.1X) and the related bug bgo#723084,
we reuse the autoconnect-retries setting to control the retry count
for requesting passwords.
I think that is wrong. These are two different settings, we should not
reuse the autoconnect retry counter while the device is still active.
For example, the user might wish to set autoconnect-retries to infinity
(zero). In that case, we would retry indefinitly to request a password.
That could be problematic, if there is a different issue with the
connection, that makes it appear tha the password is wrong.
A full re-activation might succeed, but we would never stop retrying
to authenticate. Instead, we should have two different settings for
retrying to authenticate and to autoconnect.
This is a change in behavior compared to 1.8.
It has almost no callers, and it is a bit of a strange API. Let's
not cache the last accessed value inside NMConfigData. Instead, free
it right after use. It was not reused anyway, it only hangs around
as convenience for the caller.
Names like
- nm_settings_connection_get_autoconnect_retries
- nm_settings_connection_set_autoconnect_retries
- nm_settings_connection_reset_autoconnect_retries
are about the same thing, but they are cumbersome to grep
because they share not a common prefix.
Rename them from SUBJECT_VERB_OBJECT to SUBJECT_OBJECT_VERB,
which sounds odd in English, but seems preferred to me.
Now you can grep for "nm_settings_connection_autoconnect_retries_" to
get all accessors of the retry count, or "nm_settings_connection_autoconnect_"
to get all accessors related to autoconnect in general.
When the ifcfg-rh plugin writes a 802-1x setting it currently ignores
the password-raw property and so the password disappears when the
connection is saved. Add support for the property.
31. NetworkManager-1.9.2/src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c:974:
uninit_use_in_call: Using uninitialized value "contents_rest" when
calling "__strtok_r_1c".
33. NetworkManager-1.9.2/src/nm-core-utils.c:1957:
uninit_use: Using uninitialized value "s".
148. NetworkManager-1.9.2/src/nm-core-utils.c:1924:
uninit_use_in_call: Using uninitialized value "s" when calling
"nm_strstrip_avoid_copy".
We want to support large number of routes. Reduce the number
of copies, by adding internal accessor functions.
Also, work around a complaint from coverity:
46. NetworkManager-1.9.2/libnm-core/nm-utils.c:1987:
dereference: Dereferencing a null pointer "names".
30. NetworkManager-1.9.2/src/settings/plugins/keyfile/nms-keyfile-writer.c:218:
check_return: Calling "g_mkdir_with_parents" without checking return
value (as is done elsewhere 4 out of 5
times).
25. NetworkManager-1.9.2/src/platform/nm-linux-platform.c:3969:
check_return: Calling "_nl_send_nlmsg" without checking return value (as
is done elsewhere 4 out of 5 times).
34. NetworkManager-1.9.2/src/nm-core-utils.c:2843:
negative_returns: "fd2" is passed to a parameter that cannot be negative.
26. NetworkManager-1.9.2/src/devices/wwan/nm-modem-broadband.c:897:
check_return: Calling "nm_utils_parse_inaddr_bin" without checking
return value (as is done elsewhere 4 out of 5 times).
3. NetworkManager-1.9.2/src/devices/bluetooth/nm-bluez5-manager.c:386:
check_return: Calling "g_variant_lookup" without checking return value
(as is done elsewhere 79 out of 83 times).
16. NetworkManager-1.9.2/libnm-util/nm-setting.c:405:
check_return: Calling "nm_g_object_set_property" without checking return
value (as is done elsewhere 4 out of 5 times).
Now the plugin can only recognize team or bond slaves of type
ethernet, vlan or infiniband.
Instead, check the presence of a team or bond master for all types of
connection to allow arbitrary stacking of interfaces.
NMSettingGeneric has no properties at all. Hence, nm_connection_diff() would report that
a connection A with a generic setting and a connection B without a generic setting are
equal.
They are not. For empty settings, let nm_setting_diff() return also empty difference
hash.
Before commit 3ecb57fdc4 ("settings: get rid of callback arguments
for nm_settings_connection_delete()") audit logging was done in the
callback, which was run by nm_settings_connection_delete() with a
reference to the connection to keep it alive. Now we have to keep an
extra reference to ensure it doesn't go away.
Fixes: 3ecb57fdc4
Eventually, we want to fully implement policy routing and
handle rules as well. When that happens, we will use the
route-table setting to tell NetworkManager to handle the
rule file as well.
Since we currently don't yet support that, we should reject
configuring a non-zero routing table combined with a rule file,
because later we will change behavior in that case.
We should support an arbitrary number of routes and addresses.
Arguably, our accessors for shvarFile are O(n), hence with
large ifcfg files, we will have a performance problem. The
fix for that would be to index the files.
The only implementation of can_commit() was ifcfg-rh, which
bails out with complex routes.
Note that the only caller of can_commit() (update_auth_cb()),
immidiately afterwards called nm_settings_connection_commit_changes(),
which, a few layers down in nms_ifcfg_rh_writer_write_connection()
as first thing errors out in presence of complex routes.
The check was redundant.
In general, a can_commit() function before a commit_changes() makes
no sense, because commit_changes() can just fail with error.
write_ip4_aliases() does not collect internal in-memory state, instead
it writes state to disk and deletes extraneous alias files.
It should be done after we completed our pre-run checks to generated
the data we want to write.
Instead of having set_secret() for each call open the file,
mangle it, and write it back, collect all secrets and process
them at the end once.
Also, previously set_secrets() ignored failures to write a secret and
added the secret in plain to the ifcfg file. Let's not do that.
Also, purge all other entires form the secrets file. Not only
the once that we explicitly touch.
Eventually, we should generate all configuration in-memory
first, and only after validating everything write to disk.
That avoids that we start touching files, and later encounter
a fatal error that let's us abort writing the connection.
Also, previously, we would not purge the route file if
write_ip6_setting() returns early for slave types.
- we now safe all routes we have, not limited to 256.
- we use svUnsetAll() to delete the existing keys. This is
faster then probing them one-by-one, and not limited to
256 keys (which we were checking before).
Note that we always try to load an existing file and
drop the unneeded keys. We do that, so that unrelated
entries and comments don't get the deleted. Also, so
that the order of the variables is not changed.
When calling svOpenFileInternal() with @create, we don't care about
potential errors reading the file. We shouldn't return NULL in such
case, but always create a shvarFile instance.
They are basically the same, with a minor difference where the @filename
argument determines whether to write a new file or do an update.
Also, rename them, to give them a nms_* prefix in the header file.
As writing a connection to disk might modify it, we re-read
it back and use what we actually found on disk.
For example, if you have a connection with ipv6.method=ignore,
ifcfg-rh writer will not persist the ipv6.route-metric. That
is likely a bug in the writer. Before this patch, changing
the route metric would seemingly succeed, but on the next reload
from this, the changes are lost.
We should fix such bugs. Regardless, it's better to pick up
what we wrote to disk, instead of later.
