Prevents:
Connection failed to verify: (unknown)
invalid or missing connection property 'blah blah/foo bar'
Simply removing the warning in reader.c is fine, because callers that
care already log the warning themselves. Also make the warning in
update_connection() the same as the warning in new_connection().
If a valid connection was updated and still valid, and then was
updated and become invalid, the connection would not be properly
removed from the keyfile plugin's priv->connections hash, and thus
would never be disposed.
This was due to using the direct pointer to the connection's UUID
as the key for the hash table. When a connection is updated and
its settings are replaced, the old UUID is freed and replaced with
a new pointer. But the keyfile plugin hash table still uses the
old (now freed) UUID pointer as the key. Thus when the connection
is updated and becomes invalid, looking up the UUID in the hash
table fails to find the connection, and the connection is not
removed from the hash.
This bug could cause a crash in some cases, if two keys of the
GHashTable hashed to the same value, in which case GLib would
call g_str_equal() on the freed pointer.
Since code other than in the keyfile plugin replaces settings,
we cannot be guaranteed that the pointer won't change. Avoid all
that and just strdup() the UUID when using it as a key.
(also collapses _internal_new_connection() into its only caller)
In this mode, nmtst itself will not log anything and not set the logging
level. Also, it will set g_log_set_always_fatal().
This is for tests that want to assert against all logged messages via
g_test_expect_message().
In this mode also setting the logging level via NMTST_DEBUG variable has
no effect. The test is expected to manage the logging level itself and
changing the logging level might interfere with the test.
As a showcase, move keyfile/tests/test-keyfile.c to nmtst.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When reading a hardware address in keyfile plugin, check for the
expected length already in mac_address_parser().
Before, we would call the deprecated function nm_utils_hwaddr_type()
to see if it can be some kind of MAC address. In that case, the error
was caught later during NMSetting:verify().
Signed-off-by: Thomas Haller <thaller@redhat.com>
When converting the MAC address to keyfile value, simply accept
any given byte array and pass it to nm_utils_hwaddr_ntoa_len().
This no longer restricts the length of accepted addresses as known by
nm_utils_hwaddr_type(). It is up to the caller to perform any validation
of the MAC address.
Signed-off-by: Thomas Haller <thaller@redhat.com>
- nm_utils_hwaddr_len() and nm_utils_hwaddr_type() no longer assert
against known input types/lengths. Now they can be used to detect the
hwaddr type, returning -1 on unknown.
- more checking of input arguments in nm_utils_hwaddr_aton() and
related. Also note, that nm_utils_hwaddr_aton_len() has @len of type
gsize, so we cannot pass on the output of nm_utils_hwaddr_len()
without checking for -1.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Don't call nm_utils_hwaddr_type () with random len, because it causes ugly
(NetworkManager:25325): libnm-util-CRITICAL **: file nm-utils.c: line 1989 (nm_utils_hwaddr_type): should not be reached
And add a testcase.
https://bugzilla.gnome.org/show_bug.cgi?id=730514
This results in some nice coloring. Only move the tests that are called
without arguments from check-local to TESTS.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Use g_test_expect_message() in the various daemon-side test programs,
to avoid spewing error messages when (successfully) running "make
check".
The ifnet and ifupdown plugins are extremely verbose, so they were
partially "fixed" by turning down the logging level from INFO to WARN
in those tests.
test-dhcp-options needed to be converted to gtestutils so that the
newly-added check in nm-dbus-manager would recognize it as a test
program and not try to create a private bus.
Remove the PLUGIN_PRINT() and PLUGIN_WARN() macros and use the
standard NM logging functions instead.
Also changed PLUGIN_PRINT("error: ...") to nm_log_warn("...") in
places.
Add versioned NM_DEPRECATED_IN_* and NM_AVAILABLE_IN_* macros, and tag
new/deprecated functions accordingly. (All currently-deprecated
functions are assumed to have been deprecated in 0.9.10.)
Add NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED macros which
can be set to determine which versions will cause warnings.
With the current settings, external consumers of the
libnm-util/libnm-glib APIs will have MIN_REQUIRED and MAX_ALLOWED both
set to NM_VERSION_0_9_8 by default, meaning they will get warnings
about functions added in 0.9.10. NM internally sets
NM_VERSION_MAX_ALLOWED to NM_VERSION_NEXT_STABLE to ensure that it is
always allowed to use all APIs.
Keyfile plugin writer had a bug, when writing IP6 routes with gateway
"::". Instead of writing "net/plen,,metric" it wrote "net/plen,metric".
- fix this bug and add test cases. Also, add a workaround to reader, to
accept such wrongly written IP6 routes as valid.
- change the writer for IP4 addresses, IP4 routes and IP6 routes to
omit the gateway and the metric, if it is 0.0.0.0/::/0, respectively.
Also change the reader, to accept such empty gateway as valid.
It only omits the gateway, if the metric is not 0, this means it would
write:
route1=1.2.3.4/24,0.0.0.0,1
instead of
route1=1.2.3.4/24,,1
Both representations are now supported by the reader, but older plugin
versions could only read the former (thus, we keep writing that
version).
With a metric of zero, it would instead write:
route1=1.2.3.4/24
- some refactoring and code cleanup. Fix a memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=719851
Signed-off-by: Thomas Haller <thaller@redhat.com>
Rather than explicitly passing around a UID and a flag saying whether
or not it's relevant.
(This also fixes a bug where the wrong UID was being recorded in
nm-settings-connection.c::auth_start(), which caused problems such as
agent-owned secrets not getting saved because of a perceived UID
mismatch.)
If the connection describes a bridge/bond/team/etc slave, where the
slave setting (like NMSettingBridgePort or NMSettingTeamPort) has all
default values, the setting does not get written out because the
plugin does not write default values. But then when reading the
connection back in, we need to add that all-default slave type setting
since it's required for a valid connection.
These are (most likely) only warnings and not severe bugs.
Some of these changes are mostly made to get a clean run of
Coverity without any warnings.
Error found by running Coverity scan
https://bugzilla.redhat.com/show_bug.cgi?id=1025894
Co-Authored-By: Jiří Klimeš <jklimes@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
If the connection has never been saved to disk, it won't have a path yet,
but that doesn't mean we should crash. Next, when reloading connections,
only try to do connection matching on connections that have paths, otherwise
all in-memory-only connections would be removed at the end of
read_connections().
Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
In nm_keyfile_plugin_connection_from_file(), disable the "bad owner"
check.
As root you can read all files anyway, or if necessary even chown them,
and for
other users the standard file permissions will do a fine job.
This fixes running "make check" as root.
https://bugzilla.gnome.org/show_bug.cgi?id=701112
Plugins that could save connections to disk previously depended on inotify
events from the kernel to know when to signal connection removal; that is
in response to a 'delete' request they would unlink the backing filesystem
resources, get the inotify signal, and cause NM_SETTINGS_CONNECTION_REMOVED
to be emitted.
Unsaved connections don't have any backing resources, so they would never
get the signal emitted, and NMSettings would never forget about them.
Also, when monitor-connection-files=false in the configuration, obviously
the inotify signals will never come in because they aren't set up.
Given that we can no longer rely on inotify, it's best to just explicitly
send out the NM_SETTINGS_CONNECTION_REMOVED signal whenever a connection
is deleted via the D-Bus interface or internally.
Bonding options are written straight into [bond] group like:
[bond]
interface-name=bbb
mode-active-backup
miimon=300
So we have to handle them explicitly.
Add a "monitor-connection-files" config option, which can be set to
"false" to disable automatic reloading of connections on file change.
To go with this, add a new ReloadConnections method on
o.fd.NM.Settings that can be used to manually reload connections, and
add an nm-cli command to call it.
ifcfg-rh didn't let you unmanage an InfiniBand device by hardware
address because it was recording the hardware address with uppercase
letters, while nm_match_spec_hwaddr() required lowercase. Fix this by
making nm_match_spec_hwaddr() match case-insensitively (and remove the
manual lowercasing that several other places were doing to work around
this.)
keyfile didn't let you unmanage an InfiniBand device by hardware
address because it only accepted ARPHRD_ETHER hardware addresses. Fix
that by using nm_utils_hwaddr_valid() instead.
We don't always want to immediately write new connections to disk, to
facilitate "runtime" or "temporary" connections where an interface's
runtime config isn't backed by on-disk config. Also, just because
an interface's configuration is changed doesn't necessarily mean
that new configuration should be written to disk either.
Add D-Bus methods for adding new connections and for updating existing
connections that don't immediately save the connection to disk.
Also add infrastructure to indicate to plugins that the new connection
shouldn't be immediately saved if the connection was added with the
new method.
Use the new NMConnection 'changed' signal to mark connections
as dirty/unsaved, and reset that when they get flushed to disk.
Previously, the 'Updated' signal was emitted only when the
connection was changed and flushed to disk, but now we have
more granular needs, and the signal is emitted whenever the
connection actually *is* changed, regardless of whether its
flushed to disk or not.
