This is only useful for testing. But since the managed flag is configurable
via NetworkManager.conf, there is no point in having a define as well. If
you want to test it, just configure it.
And if you really want to patch the code, then patch
"priv->unmanage_well_known" to be always TRUE.
- use _NMLOG() macro and give logging message a sensible prefix
- downgrade logging severity. Most of these messages are not
important to warrant <info> or <warn> level.
- the logging is generally rather bad. Messages like
"bind-to-connection: locking wired connection setting"
don't indicate which profile is locked to which MAC address.
TODO.
- use gs_unref_hashtable for managing lifetime
- only allocate the hashtable if necessary, and use g_hash_table_add()
which is optimized by HashTable.
- actually copy the block->name that is used as key. While not
necessary at the moment, it is very ugly how ifparser_getfirst()
returns static data. Optimally, this would be fixed and we create
and destroy the parser results. Hence, ensure the lifetime of
the key.
- initialize the hash tables in the plugins constructor, not during
initialize().
- let all dictionaries own a copy/reference of the keys and values, and
properly free them when the values are removed. In general, avoid
leaks by properly managing lifetimes.
- in @eni_ifaces, don't add a pointless dummy value "known". It has
overhead for no benefit.
NMSettingsPlugin was a glib interface, not a regular GObject
instance. Accordingly, settings plugins would implement this interface
instead of subclassing a parent type.
Refactor the code, and make NMSettingsPlugin a GObject type. Plugins
are now required to subclass this type.
Glib interfaces are more cumbersome than helpful. At least, unless
there is a good reason for using them.
Our settings plugins are all internal API and are entirely under
our control. It also means, this change is fine, as there are no
implementations outside of this source tree.
Using interfaces do would allow more flexibility in implementing the
settings plugin.
For example, the plugin would be able to derive from any other GObject
type, like NMKimchiRefrigerator. But why would we even? Let's not add monster
classes that implement house appliances beside NMSettingsPluginInterface.
The settings plugin should have one purpose only: being a settings plugin.
Hence, requiring it to subclass NMSettingsPlugin is more than resonable. We
don't need interfaces for this.
Now that NMSettingsPlugin is a regular object instance, it may also have
state, and potentially could provide common functionality for the plugin
implementation -- if that turns out to be useful. Arguably, an interface can
have state too, for example by attaching the state somewhere else (like
NMConnection does). But let's just say no.
On a minor note, this also avoids some tiny overhead that comes with
glib interfaces.
The virtual function init() naturally leads to calling the wrapper
function nm_settings_plugin_init(). However, such ${TYPE}_init() functions
are generated by G_DEFINE_TYPE().
Rename to avoid the naming conflict, which will matter next, when the
interface will be converted to a regular GObject class.
Note that while these are settings plugin, there is no public
or stable API which we need to preserve.
Previously, nms_keyfile_writer_connection() would only return @out_path, if
it differed from @existing_path. That might make sense, if we could thereby
avoid duplicating @existing_path, however, we never did that
optimization.
Just consistently always return the path, let the caller deal with this.
NetworkManager.ver needs to whitelist symbols needed by device,
settings, and ppp plugin. Fix the generator script to also allow
using c_siphash_*() symbols. These are needed by nm_hash_*().
Without this, wifi device plugin is broken.
Fixes: ccf36ff4ce
When NM has to rebuild the platform cache, it first generates ADD and
then REMOVE events for the links. So, if an interface is removed and
readded, platform will emit the ADDED event with a new ifindex while
the device with old ifindex still exists.
In such case the manager currently updates the device's ifindex but
this causes problems as the DNS manager tracks configurations by their
ifindex and so the configurations for the old device will become
stale.
Fix this by removing the device and adding it again when we detect a
change of ifindex on a device that already had valid one.
https://bugzilla.redhat.com/show_bug.cgi?id=1542366
- since commit d17d26887c, a
NMSettingsConnection no longer "is-a" NMConnection. Instead,
we must call nm_settings_connection_get_connection() to obtain
the NMConnection instance. Adjust this in mirror_8021x_connection()
- don't leak "ssid" in mirror_8021x_connection()
- move deletion of the mirror-connection to known_network_data_free().
Previously, we must have made sure that every g_hash_table_remove()
and g_hash_table_insert()(!!) first deletes the mirror connection.
Likewise, in got_object_manager() when we call g_hash_table_remove_all(),
delete created mirror connections.
- rework interface_added() to make it robust against calling
interface_added() more than once without removing the interface
in between. Essentially, this just means that we first look into
"priv->known_networks" to see whether the @id is already tracked.
And if so, delete an existing mirror-connection as necessary.
Calling g_hash_table_insert() with a key which is already hashed
will destroy the *new* key. Since @id is used below, that would
be use after free.
Fixes: d635caf940551f8f5b52683b8379a1f81c58f8fc
IWD's mechanism for connecting to EAP networks requires a network config
file to be present in IWD's storage. NM and its clients however won't
allow a connection to be attempted until a valid NMConnection is created
on the NM side for the network. To avoid duplicating the settings from
the IWD-side profiles in NM, automatically create NMSettingConnections
for EAP networks preconfigured on the IWD side, unless a matching
connection already exists. These connections will use the "external"
EAP method to mean their EAP settings can't be modified through NM, also
they won't be valid for devices configured to use the wpa_supplicant
backend unfortunately.
Those nm-generated connections can be modified by NM users (makes sense
for settings not related to the wifi authentication) in which case they
get saved as normal profiles and will not be recreated as nm-generated
connections on the next run.
I want to additionally handle deleting connections from NM clients so
that they're also forgotten by IWD, in a later patch.
To allow connections that mirror IWD's configured WPA-Enterprise
networks to be seen as valid by NM, add a new value for the eap key in
802-1x settings. 802-1x.eap stores EAP method names. In the IWD
connections we don't know what EAP method is configured and we don't
have any of the other 802-1x properties that would be required for the
settings to verify.
These connections can't be activated on devices managed by wpa_supplicant.
Make this function public. I'm not sure if at this point it makes
much sense to add a new file for iwd-specific utilities.
While there add a way for the function to return error if security
type can't be mapped to an IWD-supported security type.
The known networks hash table is indexed by the (ssid, security) tuple
for fast lookups both on DBus signals related to an IWD known network
and local NMConnection signals such as on removal.
There's no need anymore for NMIwdManager to know when a network has been
connected to, InterfaceAdded signals are now emitted when a network is
saved as a Known Network.
Before 0.5 IWD has changed the known networks API to expose separate
objects for each known network and dropped the KnownNetworks
manager-like interface so stop using that interface. Following
patches will add tracking of the known networks through
ObjectManager.
Instead of passing the return values to g_variant_get_string or
g_variant_boolean and then checking the return value of that call,
add wrappers that first check's whether the variant is non-NULL
and of the right type.
g_variant_get_string doesn't allow a NULL parameter and will also never
return NULL according to the docs.
For the State property we assume a state "unknown" and emit a warning
if the property can't be read, "unknown" is also a string in IWD itself
which would be returned if something went really wrong. In any case
this shouldn't happen.
[thaller@redhat.com: fix missing initialization of nm_auto() variable
interfaces.]
The certificate setter function like nm_setting_802_1x_set_ca_cert()
actually load the file from disk, and validate whether it is a valid
certificate. That is very wrong to do.
For one, the certificates are external files, which are not embedded
into the NMConnection. That means, strongly validating the files while
loading the ifcfg files, is wrong because:
- if validation fails, loading the file fails in its entirety with
a warning in the log. That is not helpful to the user, who now
can no longer use nmcli to fix the path of the certificate (because
the profile failed to load in the first place).
- even if the certificate is valid at load-time, there is no guarantee
that it is valid later on, when we actually try to use the file. What
good does such a validation do? nm_setting_802_1x_set_ca_cert() might
make sense during nmcli_connection_modify(). At the moment when we
create or update the profile, we do want to validate the input and
be helpful to the user. Validating the file later on, when reloading
the profile from disk seems undesirable.
- note how keyfile also does not perform such validations (for good
reasons, I presume).
Also, there is so much wrong with how ifcfg reader handles EAP files.
There is a lot of duplication, and trying to be too smart. I find it
wrong how the "eap_readers" are nested. E.g. both eap_peap_reader() and
"tls" method call to eap_tls_reader(), making it look like that
NMSetting8021x can handle multiple EAP profiles separately. But it cannot. The
802-1x profile is a flat set of properties like ca-cert and others. All
EAP methods share these properties, so having this complex parsing
is not only complicated, but also wrong. The reader should simply parse
the shell variables, and let NMSetting8021x::verify() handle validation
of the settings. Anyway, the patch does not address that.
Also, the setting of the likes of NM_SETTING_802_1X_CLIENT_CERT_PASSWORD was
awkwardly only done when
privkey_format != NM_SETTING_802_1X_CK_FORMAT_PKCS12
&& scheme == NM_SETTING_802_1X_CK_SCHEME_PKCS11
It is too smart. Just read it from file, if it contains invalid data, let
verify() reject it. That is only partly addressed.
Also note, how writer never actually writes the likes of
IEEE_8021X_CLIENT_CERT_PASSWORD. That is another bug and not fixed
either.
- rename secret related functions to have a "_secret" prefix.
Also, rename read_8021x_password() because it's not only useful
for 802-1x.
- In particular, this patch adds _secret_read_ifcfg() helper (formerly
read_8021x_password()), which is smart enough to obtain secrets from
the keys ifcfg file. We have other places where we don't get this
right.
- on a minor note, the patch also makes an effort to clear passwords
and certifcate data from memory. Yes, there are countless places
where we don't do that, but in this case, it's done and is as simple
as replacing gs_free with nm_auto_free_secret, etc.
The term "keys" is used ambigiously. Rename occurances which reference
the "keys" ifcfg-rh file.
While at it, rename the file "parsed" to "main_ifcfg". It follows the
same pattern as the "keys_ifcfg" name.
We only exposed wrappers around this function, but all of them have
different behavior, and none exposes all possible features. For example,
nm_utils_hexstr2bin() strips leading "0x", but it does not clear
the data on failure (nm_explicit_bzero()). Instead of adding more
wrappers, expose the underlying implementation, so that callers may
use the function the way they want it.
Of course, there are countless places where we get it wrong to clear
the memory. In particular, glib's GKeyFile implementation does
not care about that.
Anyway, the keyfile do contain private sensitive data. Adjust
a few places to zero out such data from memory.
NMSetting8021x has various utility functions to set
the certificate:
- nm_setting_802_1x_set_ca_cert()
- nm_setting_802_1x_set_client_cert()
- nm_setting_802_1x_set_private_key()
- nm_setting_802_1x_set_phase2_ca_cert()
- nm_setting_802_1x_set_phase2_client_cert()
- nm_setting_802_1x_set_phase2_private_key()
They support:
- accepting a plain PKCS11 URI, with scheme set to
NM_SETTING_802_1X_CK_SCHEME_PKCS11.
- accepting a filename, with scheme set to
NM_SETTING_802_1X_CK_SCHEME_BLOB or
NM_SETTING_802_1X_CK_SCHEME_PATH.
In the latter case, the function tries to load the file and verify it.
In case of the private-key setters, this also involves accepting a
password. Depending on whether the scheme is BLOB or PATH, the function
will either set the certificate to a PATH blob, or take the blob that
was read from file.
The functions seem misdesigned to me, because their behavior is
rather obscure. E.g. they behave fundamentally different, depending
on whether scheme is PKCS11 or BLOB/PATH.
Anyway, improve them:
- refactor the common code into a function _cert_impl_set(). Previously,
their non-trivial implementations were copy+pasted several times,
now they all use the same implementation.
- if the function is going to fail, don't touch the setting. Previously,
the functions would first clear the certificate before trying to
validate the input. It's more logical, that if a functions is going
to fail to check for failure first and don't modify the settings.
- not every blob can be represented. For example, if we have a blob
which starts with "file://", then there is no way to set it, simply
because we don't support a prefix for blobs (like "data:;base64,").
This means, if we try to set the certificate to a particular binary,
we must check that the binary is interpreted with the expected scheme.
Add this check.
First of all, g_warning() is not a suitable error handling. In
particular, note how this code is reached when obtaining a setting
from D-Bus, that is, the user is not at fault.
The proper way to handle this, is allowing the setter to set the invalid
value. Only later, during verify() we will fail. This way,
NetworkManager can extend the format and older libnm clients don't
break. This is how forward-compatibility (with older libnm vs. newer
daemon) is supposed to work.
- all this code duplication. Add functions and macros to simplify
the implementation of certificate properties.
Overall, pretty trival. Replace code with a macro.
