Use C-style backslash escaping to sanitize non-UTF-8 strings.
The functions are compatible with glib's g_strcompress() and
g_strescape().
The difference is only that g_strescape() escapes all non-printable,
non ASCII character as well, while nm_utils_str_utf8safe_escape()
-- depending on the flags -- preserves valid UTF-8 sequence except
backslash.
The flags allow to optionally escape ASCII control characters and
all non-ASCII (valid UTF-8) characters. But the option to preserve
valid UTF-8 (non-ASCII) characters verbatim, is what distinguishes
from g_strescape().
The agents may used this to learn that WPS PBC enrollment is active and
suggest that user pushes a button on the router instead of supplying a
network key.
nm_setting_user_set_data() rejects invalid keys and values, and
can fail. This API is correct never to fail, like the get_data()
only returns valid user-data.
However, the g_object_set() API allows to set the hash directly but
it cannot report errors for invalid values. This API is used to
initialize the value from D-Bus or keyfile, hence it is wrong
to emit g_critial() assertions for untrusted data.
It would also be wrong to silently drop all invalid date, because
then the user cannot get an error message to understand what happend.
The correct but cumbersome solution is to remember the invalid values
separately, so that verify() can report the setting as invalid.
vpn.data, bond.options, and user.data encode their values directly as
keys in keyfile. However, keys for GKeyFile may not contain characters
like '='.
We need to escape such special characters, otherwise an assertion
is hit on the server:
$ nmcli connection modify "$VPN_NAME" +vpn.data 'aa[=value'
Another example of encountering the assertion is when setting user-data key
with an invalid character "my.this=key=is=causes=a=crash".
The PMF property is an GEnum, not GFlags. We only have the GObject
property NM_SETTING_WIRELESS_SECURITY_PMF as plain integer type
to allow for future extensions.
But commonly, enums are signed int, while flags are unsigned. Change
the property to be signed for consistency.
I used to use g_strv_length ((char **) p) instead, but that feels
ugly because it g_strv_length() is not designed to operate on
arbitrary pointer arrays.
Empty secrets are fine. In particular, for PKCS#11 it means that protected
authentication path is used (the secrets are obtained on-demand from the
pinpad).
Commit a8730c51c8 moved the enum
utils from libnm-core to shared/nm-utils.
However, three of those functions are part of public API in libnm.
So, when statically linking against "shared/nm-utils/nm-enum-utils.c"
and dynamically linking against libnm.so, those symbols are present
twice and cause a linker failure.
Fix that by moving the public API back to libnm-core.
Fixes: a8730c51c8
libnm contains the public function nm_utils_enum_from_str() et al.
The function is not flexible enough for nmcli's usecase. So, I would
need another public function like nm_utils_enum_from_str_full() that
has an extended API.
That was already required previously for ifcfg-rh writer, but in that
case I could just add it as internal API as libnm-core is linked statically
with NetworkManager.
I don't want to commit to a public API for an utility function. So move
the code instead to the shared directory, so that nmcli may link
statically against it and use the internal API.
These functions are only used by nm-meta-setting-desc.c. Make them internal.
Unfortunately, they are part of "common.h" which cannot be used without
the rest of nmcli. Still todo.
This part contains static functions and variables to describe
settings. It is distinct from the mechanism to use them, or
access them.
Split it out.
It still uses clients/cli/common.h and clients/cli/utils.h
which shall be fixed next.
nm_utils_enum_to_str() may also output numeric values if there is no
corresponding "nick" for the enum/flag value.
For enums the value is in decimal and for flags the value is hexadecimal
(with a "0x" prefix).
The same was already supported by nm_utils_enum_from_str() when reading
the value. However, previously, reading a flag would only support hex
numbers and reading a enum would only support decimal numbers.
Extend that, to allow passing numbers in any base. For nm_utils_enum_to_str()
also make sure to never output nicks that may be misinterpreted as
numbers.
It is not uncommon that a flags type has also the value 0 mapped,
for example to "unknown" or "none".
In that case, we should not return an empty string, but instead
that zero value.
Also, flags actually have an unsigned type. That isn't a real
problem to cast it to a signed int. But be more careful about
it and use unsigned while handling unsigned values and only
cast to int once.
These functions return static information, and don't require
a @setting argument. The list of options is interesting even
when having now setting instance at hand.
Document this to promise the user that passing %NULL is allowed.
It was allowed since when those functions were added.
There are very few places where we actually use floating point
or #include <math.h>.
Drop that library, although we very likely still get it as indirect
dependency (e.g. on my system it is still dragged in by libsystemd.so,
libudev.so and libnl-3.so).
NMVpnConnectionStateReason is no longer used and replaced by
NMActiveConnectionStateReason. However, the old enums should
stay in place as they were:
Otherwise:
#define NMVpnConnectionStateReason NMActiveConnectionStateReason
causes compiler warnings:
NMVpnConnectionStateReason x;
x = NM_VPN_CONNECTION_STATE_REASON_UNKNOWN; // -Wenum-conversion
if (x == NM_VPN_CONNECTION_STATE_REASON_NO_SECRETS) { } // -Wenum-compare
Similarly, a user who didn't upgrade shall continue to get the
old GType for NM_TYPE_VPN_CONNECTION_STATE_REASON.
In practice, old users will have no issues using the old enum
the places where it worked before.
The only use of the deprecated enum is in vpn_state_changed()
signal slot of NMVpnConnection. This makes the signal slot
itself deprecated. However, NMVpnConnection is an NMObject and commonly
created within libnm itself, not by the user. It is very unlikely that
a user of libnm subclassed NMVpnConnection and makes use of the
vpn_state_changed() signal slot. So, deprecate it without replacement.
Fixes: a91369f80d
It includes a reason code that makes it possible for the clients to be
more reasonable about error messages.
The reason code is essentially copied from the VPN, plus three more
reasons that were useful for non-VPN connections.
In practice, this should only matter when there are multiple
header files with the same name. That is something we try
to avoid already, by giving headers a distinct name.
When building NetworkManager itself, we clearly want to use
double-quotes for including our own headers.
But we also want to do that in our public headers. For example:
./a.c
#include <stdio.h>
#include <nm-1.h>
void main() {
printf ("INCLUDED %s/nm-2.h\n", SYMB);
}
./1/nm-1.h
#include <nm-2.h>
./1/nm-2.h
#define SYMB "1"
./2/nm-2.h
#define SYMB "2"
$ cc -I./2 -I./1 ./a.c
$ ./a.out
INCLUDED 2/nm-2.h
Exceptions to this are
- headers in "shared/nm-utils" that include <NetworkManager.h>. These
headers are copied into projects and hence used like headers owned by
those projects.
- examples/C
For IPv4 we support both the legacy and the new route file format. In
the legacy format, option are appended to the "ip route" command
arguments:
203.0.113.0/24 metric 3 via 198.51.100.1 dev eth2 cwnd 14 mtu lock 1500
This is backwards compatible with initscripts. In the new format, a
OPTIONSx= variable is added to represent the options in the same
format understood by iproute2:
ADDRESS0=203.0.113.0
NETMASK0=255.255.255.0
GATEWAY0=198.51.100.1
METRIC0=3
OPTIONS0="cwnd 14 mtu lock 1500"
initscripts do not support this variable at the moment (but the
changes needed to support it are trivial).
By default the new format is used, unless the route file is already in
the legacy format.
For IPv6 only the legacy format is supported, as before.
This adds definition of a set of known route option attributes to
libnm-core and helper functions.
nm_ip_route_attribute_validate() performs the validation of the
attribute type and, in case of a formatted string attribute, of its
content.
nm_ip_route_get_variant_attribute_spec() returns the attribute format
specifier to be passed to nm_utils_parse_variant_attributes(). Since
at the moment NMIPRoute is the only user of NMVariantAttributeSpec and
the type is opaque to users of the library, the struct is extended to
carry some other data useful for validation.
Various libnm objects (addresses, routes) carry an hash table of
attributes represented as GVariants indexed by name. Add common
routines to convert to and from a string representation.
To parse a string, a knowledge of the supported attributes (and their
types) is needed: we represent it as an opaque type
NMVariantAttributeSpec that callers must query to the library for the
specific object type and pass to the parse function.
