Now that NMPlatformIP[46]Route can contain a wildcard table/metric, we
can set the effectivey table/metric per NML3ConfigData that we merge.
Pass it to nm_l3cfg_add_config().
When we (for example) receive a DHCP lease, we track the routes that
should be configured via NMPlatformIP[46]Route instances. Thus, this
structure does not only track the routes that are configured (and
cached in NMPlatform), but it is also used to track the routes that
we want to configure.
This is also the case with the "rt_source" field, which represents the
NMIPConfigSource enum for routes that we want to configure, but
for routes in the cache it corresponds to rtm_protocol.
Note that NMDhcpClient creates NMIP4Config instances, which tracks the
routes as NMPlatformIP4Route instances. Previously, NMDhcpClient didn't
have any way to leave the table/metric undecided, but this information
isn't part of the DHCP lease tself. Instead, NMDevice knows the table/metric
to use. This has various problems:
- NMDhcpClient needs to know the table/metric, for no other purpose
than to set the value when creating the NMIP4Config instance for the
lease. We first pass the information down, only so that it can be
returned with the lease information.
- during reapply or when connectivity check changes, the effectively
used table/metric can change. Previously, we would have to
re-generate the NMIP4Config instances.
Improve that by allowing to leave the table/metric undecided. Higher
layers can decide the effective metric to use.
Kernel uses such typedefs (__le32) and systemd too (le32_t).
As we don't want to rely on systemd headers in our code
base, let's also define them.
They have of course very little effect beside making it clearer to
the reviewer that a certain variable is not supposed to be in native
endianness.
While we often use and prefer the glib typedefs (like guint32), there
are places where we want to use the fixed width integer types from C99.
In particular, next we will introduce typedefs like nm_le64_t for
integers in different endianness.
Also, here we are about "nm-std-aux", so the glib typedefs are not
available.
I feel a header like <stdint.h> is such a basic C requirement, that
is should just be available to us everywhere.
I would need these macros earlier in "nm-glib-aux/nm-shared-utils.h",
so it would be sufficient to just move them.
However, when I already move them, move them to "nm-std-aux/nm-std-aux.h"
because they don't need a glib dependency.
We use clang-format to format our code, and the exact format depends on
the clang version. Currently we use clang-11, as packaged in Fedora 33.
Add a script that runs a Fedora 33 container with podman and reformats
the current working directory.
Usage:
./contrib/scripts/nm-code-format-container.sh
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
Compare to the connection's GetSettings() call, which is not protected
by policykit permissions. It only checks that the requesting user is
allowed according to "connection.permission".
Previously, device's GetAppliedConnection() requires "network-control"
permissions. This although it only reads a profile, without modifying
anything. That seems unnecessary, also because in the common case the
applied connection is identical to the current settings connection, and
the latter can be read without special permissions.
Don't require a special policykit permission to read the applied
connection.
https://bugzilla.redhat.com/show_bug.cgi?id=1882380
There is no need spawn up two containers (and install similar packages, doing so is
resource intensive), to run two different tests. We can run them in the same
container.
At this point Fedora 33 is not yet fully released. But it will happen soon, so the
image is stable enough for these kinds of tests (and will only get more
stable in the following weeks).
Also no longer collect an artifact with the test output. The test output
is already nicely visible in the gitlab-ci UI. No need to collect it
separately.
Run:
./contrib/scripts/nm-code-format.sh -i
./contrib/scripts/nm-code-format.sh -i
Yes, it needs to run twice because the first run doesn't yet produce the
final result.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
clang-format will re-format this in multiple lines, use C comment
to not break compilation after applying code-style with clang-format.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
glib-mkenums doesn't work with enums on single line
or with enums entries that span multiple lines, turn off
automatic formatting for these special cases to not break
docs generation.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
Our new format gets enforced by clang-format, and we now only use
four space indentation, instead of tabs.
Adjust the checkpatch script to account for that.
Also, now there are probably no cases left where we want to see any
tabs in our sources. Complain about any tabs we find.
These are inspired by systemd.
We should replace our calls to getpwuid() and getpwnam() with
their thread safe variants.
We run possibly multiple threads (e.g. helper threads from GDBus and
GResolver). It's hard to be sure that they don't also access the
functions.
Adding NML3Cfg support is a large effort that is done in parallel.
While already parts of the code is merged, it is not actually used
yet. Remove the parts from NMDevice that interact with NML3Cfg
before we actually start using it.
The point is that we might want to do a release before switching
over to the new way. For that release, we should not have the unused
code in NMDevice.
This patch will later be restored and extended.
But also take a reference whenever we have any configurations
registered. Registering a configuration means to automatically
keep the instance alive.
Any user must take care to unregister again when it no longer requires
the configuration.
