We support the "NetworkManager.conf" sections '[connection]' and
'[connection.\+]' (with arbitrary suffix).
Fix the order of how we evaluate these section.
Note that the literal '[connection]' section is always evaluated lastly
after any other '[connection.\+]' section.
Within one file, we want to evaluate the sections in top-to-bottom
order. But accross multiple files, we want to order them
later-files-first. That gives a reasonable behavior if the user
looks at one file, and also if he wants to overwrite configuration
via configuration snippets like "conf.d/99-last.conf".
Note that if a later file extends/overwrites a section defined in an
earlier file, the section is still considered with lower priority
This is intentional, because the user ~extends~ a lower priority
section. If he wants to add a higher priority section, he should
choose a new suffix.
Fixes: dc0193ac02
(cherry picked from commit f8c9863d55)
Under certain cases, if g_key_file_get_groups() fails, it might not set the
out argument @length. Play it safe and initialize it.
(cherry picked from commit aa7a53bc67)
The original backport was different then what was done on master.
Make 'nm-config.c' more similar to what we have on master.
Fixes: d510f0a039
(cherry picked from commit 643f042b9b)
Renable checking owner of keyfile files but disable that
behavior for tests.
For that, add a nm_utils_get_testing() function to core to detect
whether the code is running as part of a test.
https://bugzilla.gnome.org/show_bug.cgi?id=701112
(cherry picked from commit 046115b588)
Code that is testable often needs special hooks to work
both for unit-tests and production.
Add a function nm_utils_get_testing() that returns whether
the code is run as part of a unit-test.
For non-testing mode, nm_utils_get_testing() will return
zero (NM_UTILS_TEST_NONE). For unit tests, the test should call
_nm_utils_set_testing() to configure tested functions.
By specifing the @flags attribute, the test can enable/disable
specific behaviors.
https://bugzilla.gnome.org/show_bug.cgi?id=701112
(cherry picked from commit b9d8dc050a)
_keyfile_convert() should really test for successful round-trip
conversion of keyfile-connection and vice versa.
(cherry picked from commit 81119c69d8)
Move basic keyfile functionality from settings plugin to libnm-core.
This is a first step to have a semi-standard way to stringify
connections back and forth, which is also available to libnm users.
Still the new functions are internal API (nm-keyfile-internal.h).
Let's decide later how the public API should really look like.
https://bugzilla.gnome.org/show_bug.cgi?id=744699
(cherry picked from commit 59eb5312a5)
keyfile should become our main import/export format. It is desirable,
that a keyfile can contain every aspect of a connection.
For blob certificates, the writer in core daemon would always write
them to a file and convert the scheme to path.
This behavior is not great for a (hyptetical) `nmcli connection export`
command because it would have to export them somehow outside of keyfile,
e.g. by writing them to temporary files.
Instead, if the write handler does not handle a certificate, use a
default implementation in nm_keyfile_write() which adds the blob inside
the keyfile.
Interestingly, keyfile reader already supported reading certificate
blobs. But this legacy format accepts the blob as arbitrary
binary without marking the format and without scheme prefix.
Instead of writing the binary data directly, write it with a new
uri scheme "data:;base64," and encode it in base64.
Also go through some lengths to make sure that whatever path
keyfile plugin writes, can be read back again. That is, because
keyfile writer preferably writes relative paths without prefix.
Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate
the detection of pathnames without file:// prefix and use it to
check whether the path name must be fully qualified.
(cherry picked from commit c9a8764ad2)
These headers are not entirely private to libnm-core as they are also
used by keyfile plugin. Merge them to a new header file
nm-keyfile-internal.h so that the name makes the internal nature of the
header more apparent.
(cherry picked from commit 5e5afcffce)
This is the first step to move keyfile to libnm. For now, only
copy the files to make later changes nicer in git-history.
/bin/cp src/settings/plugins/keyfile/reader.c libnm-core/nm-keyfile-reader.c
/bin/cp src/settings/plugins/keyfile/reader.h libnm-core/nm-keyfile-reader.h
/bin/cp src/settings/plugins/keyfile/utils.c libnm-core/nm-keyfile-utils.c
/bin/cp src/settings/plugins/keyfile/utils.h libnm-core/nm-keyfile-utils.h
/bin/cp src/settings/plugins/keyfile/writer.c libnm-core/nm-keyfile-writer.c
/bin/cp src/settings/plugins/keyfile/writer.h libnm-core/nm-keyfile-writer.h
(cherry picked from commit 1fc9bc401e)
nm_keyfile_plugin_kf_get_integer_list() should always set
@length to zero when returning no integer list. So, this
is probably correct. Still, just to be explicit, anticipate
and handle a missing @tmp_list.
(cherry picked from commit f430774ca0)
When setting the certificate glib properties directly,
we raise a g_warning() when the binary data is invalid.
But since the caller has no access to the validation function,
he cannot easily check whether his action will result
in a warning. Add nm_setting_802_1x_check_cert_scheme() for
that.
While backporting, hide public API from 1.2.
(cherry picked from commit 15926e9eb3)
A valid blob cannot start with "file://", otherwise it would
break the implementation of the certificate properties in
NMSetting8021x. Simply reject every blob in nm_setting_802_1x_set_ca_cert()
et al. that is not valid according to get_cert_scheme().
(cherry picked from commit cda7b158e2)
get_cert_scheme() would return PATH scheme for binary data that
later will be rejected by verify_cert(). Even worse, get_cert_scheme()
would not check whether the path is NUL terminated, hence the following
can crash for an invalid connection:
if (nm_setting_802_1x_get_ca_cert_scheme (s_8021x) == NM_SETTING_802_1X_CK_SCHEME_PATH)
g_print ("path: %s", nm_setting_802_1x_get_ca_cert_path (s_8021x))
Combine the two functions so that already get_cert_scheme() does
the same validation as verify_cert().
Also change behavior and be more strict about invalid paths:
- Now, the value is considered a PATH candidate if it starts with "file://",
(sans NUL character).
A change is that before, the "file://" (without NUL) would have
been treated as BLOB, now it is an invalid PATH (UNKNOWN).
- If the binary starts with "file://" it is considered as PATH but it
is only valid, if all the fllowing is true:
(a) the last character must be NUL.
(b) there is no other intermediate NUL character.
Before, an intermediate NUL character would have been accepted
and the remainder would be ignored.
(c) there is at least one non-NUL character after "file://".
(d) the string must be fully valid utf8.
The conditions (b) and (c) are new and some invalid(?) paths
might no longer validate.
Checking (d) moved from verify_cert() to get_cert_scheme().
As set_cert_prop_helper() already called verify_cert(), this
causes no additional change beyond (b).
(cherry picked from commit e59e68c528)
This changes behavior, in that we now ignore keyfiles that
start with a dot ('.'). This means, that connection with ids
starting with a dot, will be ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=735824
(cherry picked from commit 6ccb888831)
read_field() was supposed to set *error to NULL if there was no error,
but it missed one case. (If **current was '\0'.)
(cherry picked from commit d746103d75)
We have nm_keyfile_plugin_utils_should_ignore_file() to ignore certain
files based on patterns. We also need a matching escape function to
avoid saving connections with a name we would ignore later.
https://bugzilla.gnome.org/show_bug.cgi?id=735824
(cherry picked from commit a823217b1f)
This gets called for all links via link_get_permanent_address(). This could
easily be an infiniband address and we don't want to assert it's not.
(cherry picked from commit 31c8bd6b69)
