This wouldn't even dereference the dangling pointer, but
merely comparing it for pointer equality. Still, it's actually
undefined behavior. Avoid it.
(cherry picked from commit cfc0565604)
This is a change in behavior regarding the filename that we choose when
writing files to "/etc/NetworkManager/system-connections/".
(cherry picked from commit d37ad15f12)
initrd does not use keyfile API from "src/settings/plugins/keyfile",
hence it does not use nms_keyfile_utils_escape_filename() to add
the ".nmconnection" file extension.
I think that is problematic, because it also misses escapings which
are necessary so that NetworkManager will accept the file.
Anyway, the proper solution here would be to move the keyfile utility
functions to libnm-core, alongside base keyfile API. That way, it
could be used by initrd generator.
For now, just dirty fix the generated filename.
Fixes: 648c256b90
(cherry picked from commit 4ca7fa7f4a)
For profiles in "/etc/NetworkManager/system-connections", we did not enforce
that the keyfiles have a special suffix, nor did we generate the
filenames in such a manner. In hindsight, I think that was a mistake.
Recently we added "/run/NetworkManager/system-connections" as additional
keyfile directory. Enforce a suffix and write keyfiles with such a name.
In principle, we could also start writing keyfiles in /etc with the
same suffix. But let's not do that, because we anyway cannot enforce
it.
An ugly part is, that during `nmcli connection load` we need to
determine whether the to-be-loaded connection is under /etc or /run.
Preferably, we would allow any kind of symlinking as what matters
is the file object (inode) and not the path. Anyway, we don't do
that but compare plain paths. That means, paths which are not
in an expected form, will be rejected. In particular, the paths
starting with "/run/..." and "/var/run/..." will be treated differently,
and one of them will be rejected.
Note that ifcfg-rh plugin strictly enforces that the path
starts with IFCFG_DIR as well. So, while this is a breaking
change for keyfile, I think it's reasonable.
(cherry picked from commit 648c256b90)
keyfile already supports omitting the "connection.id" and
"connection.uuid". In that case, the ID would be taken from the
keyfile's name, and the UUID was generated by md5 hashing the
full filename.
No longer do this during nm_keyfile_read(), instead let all
callers call nm_keyfile_read_ensure_*() to their liking. This is done
for two reasons:
- a minor reason is, that one day we want to expose keyfile API
as public API. That means, we also want to read keyfiles from
stdin, where there is no filename available. The implementation
which parses stdio needs to define their own way of auto-generating
ID and UUID. Note how nm_keyfile_read()'s API no longer takes a
filename as argument, which would be awkward for the stdin case.
- Currently, we only support one keyfile directory, which (configurably)
is "/etc/NetworkManager/system-connections".
In the future, we want to support multiple keyfile dirctories, like
"/var/run/NetworkManager/profiles" or "/usr/lib/NetworkManager/profiles".
Here we want that a file "foo" (which does not specify a UUID) gets the
same UUID regardless of the directory it is in. That seems better, because
then the UUID won't change as you move the file between directories.
Yes, that means, that the same UUID will be provided by multiple
files, but NetworkManager must already cope with that situation anyway.
Unfortunately, the UUID generation scheme hashes the full path. That
means, we must hash the path name of the file "foo" inside the
original "system-connections" directory.
Refactor the code so that it accounds for a difference between the
filename of the keyfile, and the profile_dir used for generating
the UUID.
(cherry picked from commit 837d44ffa4)
check_prefix() was only ever called with "." as prefix.
Simplify the implementation to explicitly check for a leading
dot.
(cherry picked from commit 2e5985f2e9)
nm-initrd-generator scans the command line for options relevant to network
configuration and creates configuration files for an early instance of
NetworkManager run from the initial ramdisk during early boot.
(cherry picked from commit 9f9609555d)
This is loosely based on nms-ibft-reader, but with some significant
changes. Notably, it parses /sys/firmware/ibft directly instead of
iscsiadm output.
iscsiadm is not available on early boot (perhaps it's too large) and
turns out that parsing sysfs directly is easier and more
straightforwared anyways. A win-win situation.
It is not useful alone, it's in a separate commit just for the sake of
easier review.
(cherry picked from commit b544f7243d)
We need a mode that:
* doesn't leave processes behind
* doesn't force an internal dhclient
* doesn't auto-generate default connections
* doesn't write out files into libdir, only /run
The original configure-and-quit mode doesn't really fit the initrd use. But
it's proobably not a good idea to just change its behavior.
(cherry picked from commit c263f5355c)
This is useful for in-memory connections to persist NetworkManager
restarts (as opposed to machine restarts).
Perhaps most improtantly, this allows generating in-memory connections outside
NetworkManager, e.g. passing configuration from early boot firmware in initrd.
Note that this does *not* aspire to do more than it says on the tin:
Notably, it doesn't touch the problem of provisioning connections in multiple
persistent connection directories and thus doesn't have to deal with the
problem of deleting or overlaying the connections tha (rh #772414) deals
with.
(cherry picked from commit ce4dbd7daf)
Especially with configure-and-quit, it's easy to encounter a condition,
where the device reached a failed state, policy decides to quit, but the
active connection is not yet torn down from the device.
Upon the next start NetworkManager would think the connection succeeded
activating.
(cherry picked from commit e98ebc7e3b)
Make them just ask for connections from GDBus, as other D-Bus clients
do. GDBus anyway reuses the connection if it has one, but allows us to
deal with errors in a more civilized manner.
(cherry picked from commit e1fc005239)
Using these unormalized was wrong all along, but by chance didn't hit
paths that needed normalized connections. This may change if we
actually write in memory connections to /run with the keyfile plugin,
because that one wants them normalized.
This also saves some work, because normalization does boring things for
us, such as adding default ipv4/ipv6/proxy settings everywhere.
(cherry picked from commit 89d1c9fb30)
On networked boot we need to somehow communicate this to the early boot
machinery. Sadly, no DBus there and we're running in configure-and-quit
mode.
Abusing the state file for this sounds almost reasonable and is
reasonably straightforward thing to do.
(cherry picked from commit 55d24ba94e)
When a device is unmanaged, an explicit activation request can
still activate it. In particular, that is the case for
$ nmcli connection up "$PROFILE" ifname "$DEVICE"
It is also the case, for plain
$ nmcli connection up "$PROFILE"
where NetworkManager searches for a suitable device -- depending on
multi-connect setting of the profile.
The idea is, that a profile with "multi-connect=single" is expected
to sufficently and uniquely match a device, based on matching properties
like "connection.interface-name". In that case, an explicit activation
request from the user shows the intent to manage the device.
Note that it's hard to understand whether the profile really uniquely
selects a particular device. For example, if the profile doesn't specify
"connection.interface-name", it might still uniquely identify
an ethernet device, if you only have one such device.
On the other hand, with "connection.multi-connect" other than "single",
it is very much expected that the profile does not strictly match
one device.
Change the behavior here for multi-connect profiles. This allows the
user to block individual devices from activation via
$ nmcli device set "$DEVICE" managed not
A subsequent
$ nmcli connection up "$MULTI_PROFILE"
will not consider "$DEVICE" as suitable candidate for activation.
Likewise, in the future we may want to add a
$ nmcli connection up --all "$MULTI_PROFILE"
command, to activate the profile on all suitable device.
In that case again, unmanaged devices probably also should be skipped
for multi-connect profiles.
https://bugzilla.redhat.com/show_bug.cgi?id=1639254
(cherry picked from commit 0cb8bed23c)
This flag is more granular in whether to consider the connection
available or not. We probably should never check for the combined
flag NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST directly, but
always explicitly for the relevant parts.
Also, improve the error message, to indicate whether the device is
strictly unmanaged or whether it could be overruled.
(cherry picked from commit 920346a5b9)
The flags NMDeviceCheckConAvailableFlags and NMDeviceCheckDevAvailableFlags
both control whether a device appears available (either, available in
general, or related to a particular profile).
Also, both flag types strictly increase availability. Meaning: more flags,
more available.
There is some overlap between the flags, however they still have
their own distinct parts.
Improve the mapping from NMDeviceCheckConAvailableFlags to
NMDeviceCheckDevAvailableFlags, by picking exactly the flags
that are relevant.
(cherry picked from commit 5412fd389b)
With
$ nmcli connection up "$PROFILE" ifname "$DEVICE"
it's clear that the user means the particular device. That also
is taken as a indication to make $DEVICE as managed, in case it was
unmanaged before. So, this command implies a previous
$ nmcli device set $DEVICE managed yes
On the other hand, if the user just issues
$ nmcli connection up "$PROFILE"
without a particular device, then we should prefer devices which
are marked as managed instead of unmanaged once.
Likewise, we should consider the device's state when selecting
a device. This means, when activating a profile which is activatable on
multiple devices, it will now prefer devices which are not already
active. The exception to this is that if the profile itself is already
active (and multi-connect "single"), then it will prefer to re-activate
the profile on the same device. This was done previously already. What's
new is that if the the profile is not multi-connect "single", the said
exception no longer applies, and we prefer to activate the profile on a
hitherto unactivated device.
https://bugzilla.redhat.com/show_bug.cgi?id=1639254https://github.com/NetworkManager/NetworkManager/pull/232
(cherry picked from commit 09719bc479)
I am not sure, we ever call complete_address() for router-configurations.
Maybe not, so the dad-counter is never incremented and does not matter either.
If we however do, then we certainly want to preserve the DAD counter
when the address is already tracked.
(cherry picked from commit 8c6629b356)
we use get_expiry() to compare two lifetimes. Note, that previously,
it would correctly truncate the calculated expiry at G_MAXINT32-1.
However, that means, that two different lifetimes that both lie
more than 68 years in the future would compare equal.
Fix that, but extending the range to int64, so that no overflow
can happen.
(cherry picked from commit b086535cb7)
RFC4862 5.5.3, points d) and e) make it clear, that the list of
addresses should be compared based on the prefix.
d) If the prefix advertised is not equal to the prefix of an
address configured by stateless autoconfiguration already in the
list of addresses associated with the interface (where "equal"
means the two prefix lengths are the same and the first prefix-
length bits of the prefixes are identical), and if the Valid
Lifetime is not 0, form an address (and add it to the list) by
combining the advertised prefix with an interface identifier of
the link as follows:
That means, we should not initialize the interface identifier first
(via complete_address()) and then search for the full address.
See-also: https://tools.ietf.org/search/rfc4862#section-5.5.3
(cherry picked from commit 23c417854a)
Previously, we would coerce the value so that preferred is the same
as lifetime. However, RFC4862 5.5.3.c) says:
c) If the preferred lifetime is greater than the valid lifetime,
silently ignore the Prefix Information option. A node MAY wish to
log a system management error in this case.
See-also: https://tools.ietf.org/search/rfc4862#section-5.5.3
(cherry picked from commit 43c3c259c8)
