nm_settings_get_connections() returns a sorted list. We have many users
of nm_connection_provider_get_connection(), which returns the same result,
but undefined order.
Next NMConnectionProvider will be dropped. Thus, we don't want to
seamlessly replace nm_connection_provider_get_connection() by a sorted
version nm_settings_get_connections().
Rename nm_settings_get_connections() to make clear it is sorted.
g_file_read_link() "reads" the symbolic link. If it's a relative path,
we get a relative path which is anchored on @file. We must resolve that
to be absolute.
The notification was missing from a long time. The issue has been exposed only
now due to the c57e5a6b66 fix which properly
implemented the "startup-complete" notification substituting out of place code
which masked the bug.
We connect to notify::startup-complete signal of each connection,
but after we signal startup-complete once, we don't need that
signal anymore. Disconnect.
Generate a stable connection UUID for the default-wired-connection.
Otherwise, on every reboot, the UUID changes although the generated
connection is the same.
But also hash into the UUID the machine-id, the device name and the
hardware address. So, the UUID is only the same if the connection is
identical in every aspect.
Also, the UUID is used as Network_ID for the stable-privacy address
generation mode. It is bad to re-create different UUIDs on every boot
as it causes different addresses.
The main purpose of audit logging is to understand who did what to the
system configuration, so it is useful to log also the list of changed
properties when a connection is updated:
op="connection-update"
uuid="2f3e48fc-5f47-41d9-9278-d2871378df43"
name="pppoe1"
args="pppoe.username,pppoe.password" <========
pid=9523
uid=1001
result="success"
This is mostly interesting of NMPolicy, which no longer needs to
subscribe to two almost identical signals (where the by-user signal
was always invoked together with the plain "updated" signal).
Instead of connecting to two similar signals, combine them into one
and pass "by_user" argument.
We still need to keep the original NM_SETTINGS_CONNECTION_UPDATED signal,
because it is exposed on D-Bus.
Due to a bug, NMManager would connect to "notify::connections"
and might miss an important notification when NMSettings declares
startup-complete.
Fixes: b067ca7034
There is no excuse for clients to send connections to NetworkManager
that have invalid/unknown fields. Just reject them.
This is a dangerous change, because we might now reject connections
that we were accepting previously. Who know what clients were sending
and it used to work.
In commit 6dc35e66d4 ("settings: add hostnamed support") we started
to use systemd-hostnamed for setting the system static hostname
(i.e. the one written to /etc/hostname), but nm-policy.c still called
sethostname() to set the transient (dynamic) hostname when this needs
to be changed, for example after a reverse lookup of our dynamic IP
address.
Thus, when using systemd the hostname change failed because process'
capabilities are restricted and sethostname() requires CAP_SYS_ADMIN.
We should set also the transient hostname through hostnamed when this
is available.
https://bugzilla.redhat.com/show_bug.cgi?id=1308974
Functions that take a GError** MUST fill it in on error. There is no
need to check whether error is NULL if the function it was passed to
had a failing return value.
Likewise, a proper GError must have a non-NULL message, so there's no
need to double-check that either.
Based-on-patch-by: Dan Winship <danw@gnome.org>
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
Get rid of NM_UNMANAGED_DEFAULT and refine the interaction between
unmanaged flags, device state and managed property.
Previously, the NM_UNMANAGED_DEFAULT was special in that a device was
still considered managed if it had solely the NM_UNMANAGED_DEFAULT flag
set and its state was managed. Thus, whether the device (state) was managed,
depended on the device state too.
Now, a device is considered managed (or unmanaged) based on the unmanaged
flags and realization state alone. At the same time, the device state
directly corresponds to the managed property of the device. Of course,
while changing the unmanaged flags, that invariant is shortly violated
until the state transistion is complete.
Introduce more unmanaged flags whereas some of them are non-authorative.
For example, the EXTERNAL_DOWN flag has only effect as long as the user
didn't explicitly manage the device (NM_UNMANAGED_USER_EXPLICIT). In other
words, certain flags can render other flags ineffective. Whether the device
is considered managed depends on the flags but also at the explicitly unset flags.
In a way, this is similar to previous where NM_UNMANAGED_DEFAULT was ignored
(if no other flags were present).
Also, previously a device that was NM_UNMANAGED_DEFAULT and in disconnected
state would transition back to unmanaged. No longer do that. Once a device is
managed, it stays managed as long as the flags indicate it should be managed.
However, the user can also modify the unmanaged flags via the D-Bus API.
Also get rid or nm_device_finish_init(). That was previously called
by NMManager after add_device(). As we now realize devices (possibly
multiple times) this should be handled during realization.
https://bugzilla.gnome.org/show_bug.cgi?id=746566
We inconsistently use gulong,guint,int types to store signal handler
id, but the type returned by g_signal_connect() is a gulong.
This has no practical consequences because a int/guint is enough to
store the value, however it is better to use a consistent type, also
because nm_clear_g_signal_handler() accepts a pointer to the signal id
and thus it must be always called with the same pointer type.
This property is TRUE for devices that exist either as a kernel device
or are backed by some other resource (eg, ModemManager object, Bluez
device, etc). It will eventually be FALSE for software devices that
are not yet instantiated.
Previously most objects were implicitly unexported when they were
destroyed, but since refcounts may make the object live longer than
intended, we should explicitly unexport them when they should no
longer be present on the bus.
This means we can assume that objects will always be un-exported
already when they are destroyed, *except* when quitting where most
objects will live until exit because NM leaves interfaces up and
running on quit.
Clone the connection upon activation. This makes it safe for the user
to modify the original connection while it is activated.
This involves several changes:
- NMActiveConnection gets @settings_connection and @applied_connection.
To support add-and-activate, we constructing a NMActiveConnection with
no connection set. Previously, we would set the "connection" field to
a temporary NMConnection. Now NMManager piggybacks this temporary
connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE).
- get rid of the functions nm_active_connection_get_connection_type()
and nm_active_connection_get_connection_uuid(). From their names
it is unclear whether this returns the settings or applied connection.
The (few) callers should figure that out themselves.
- rename nm_active_connection_get_id() to
nm_active_connection_get_settings_connection_id(). This function
is only used internally for logging.
- dispatcher calls now get two connections as well. The
applied-connection is used for the connection data, while
the settings-connection is used for the connection path.
- needs special handling for properties that apply immediately
when changed (nm_device_reapply_settings_immediately()).
Co-Authored-By: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=724041
NMSecretAgent (and in turn NMAgentManager) used the @connection argument both
for the connection data, but also for the connection path. Detangle these, and
accept the path separate from the connection.
This makes NMSecretAgent and NMAgentManager truly operate on a plain
NMConnection, without the non-obvious requirement, that the path of the
connection must be set.
A GObject interface, like a class, has two different C types
associated with it; the type of the "class" struct (eg, GObjectClass,
GFileIface), and the type of instances of that class/interface (eg,
GObject, GFile).
NetworkManager was doing this wrong though, and using the same C type
to point to both the interface's class struct and to instances of the
interface. This ends up not actually breaking anything, since for
interface types, the instance type is a non-dereferenceable dummy type
anyway. But it's wrong, since if, eg, NMDeviceFactory is a struct type
containing members "start", "device_added", etc, then you should not
be using an NMDeviceFactory* to point to an object that does not
contain those members.
Fix this by splitting NMDeviceFactory into NMDeviceFactoryInterface
and NMDeviceFactory; by splitting NMConnectionProvider into
NMConnectionProviderInterface and NMConnectionProvider; and by
splitting NMSettingsPlugin into NMSettingsPluginInterface and
NMSettingsPlugin; and then use the right types in the right places.
As a bonus, this also lets us now use G_DEFINE_INTERFACE.
Since there have not been separate system and user settings services
since 0.8, the "system" in NMSystemConfigInterface is kind of
meaningless. Rename it to NMSettingsPlugin, which describes what it
does better.
This is just:
git mv src/settings/nm-system-config-interface.h src/settings/nm-settings-plugin.h
git mv src/settings/nm-system-config-interface.c src/settings/nm-settings-plugin.c
perl -pi -e 's/SystemConfigInterface/SettingsPlugin/g;' \
-e 's/system_config_interface/settings_plugin/g;' \
-e 's/system-config-interface/settings-plugin/g;' \
-e 's/SYSTEM_CONFIG_INTERFACE/SETTINGS_PLUGIN/g;' \
-e 's/sc_plugin/settings_plugin/g;' \
-e 's/SC_PLUGIN/SETTINGS_PLUGIN/g;' \
-e 's/SC_IS_PLUGIN/SETTINGS_IS_PLUGIN/g;' \
-e 's/SC_TYPE_PLUGIN/SETTINGS_TYPE_PLUGIN/g;' \
-e 's/SCPlugin/SettingsPlugin/g;' \
-e 's/nm_system_config_factory/nm_settings_plugin_factory/g;' \
$(find src/settings -type f)
(followed by some whitespace fixups in nm-settings-plugin.c, and a
Makefile.am fix for the rename)
Program received signal SIGSEGV, Segmentation fault.
g_type_check_instance_cast (type_instance=type_instance@entry=0x89f180, iface_type=9004512) at gtype.c:4060
4060 node = lookup_type_node_I (type_instance->g_class->g_type);
(gdb) bt
#0 0x00007ffff4b44e80 in g_type_check_instance_cast (type_instance=type_instance@entry=0x89f180, iface_type=9004512) at gtype.c:4060
#1 0x000000000056a460 in connection_visibility_changed (connection=0x89f680 [NMKeyfileConnection], pspec=<optimized out>, user_data=0x89f180) at settings/nm-settings.c:870
#5 0x00007ffff4b3b54f in <emit signal notify:visible on instance 0x89f680 [NMKeyfileConnection]> (instance=instance@entry=0x89f680, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3393
#2 0x00007ffff4b200b5 in g_closure_invoke (closure=0x9131a0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffd540, invocation_hint=invocation_hint@entry=0x7fffffffd4c0) at gclosure.c:801
#3 0x00007ffff4b32499 in signal_emit_unlocked_R (node=node@entry=0x8696b0, detail=detail@entry=641, instance=instance@entry=0x89f680, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd540) at gsignal.c:3581
#4 0x00007ffff4b3b1a0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd710) at gsignal.c:3337
#6 0x00007ffff4b24665 in g_object_dispatch_properties_changed (object=0x89f680 [NMKeyfileConnection], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1056
#7 0x00007ffff4b26d11 in g_object_notify (pspec=0x8ce660 [GParamBoolean], object=0x89f680 [NMKeyfileConnection]) at gobject.c:1149
#8 0x00007ffff4b26d11 in g_object_notify (object=0x89f680 [NMKeyfileConnection], property_name=property_name@entry=0x5d2eb9 "visible") at gobject.c:1197
#9 0x0000000000497f85 in set_visible (self=self@entry=0x89f680 [NMKeyfileConnection], new_visible=new_visible@entry=0) at settings/nm-settings-connection.c:296
#10 0x0000000000498165 in dispose (object=0x89f680 [NMKeyfileConnection]) at settings/nm-settings-connection.c:2390
#11 0x00007ffff4b24fec in g_object_unref (_object=0x89f680) at gobject.c:3137
#12 0x00000000004a4a4f in dispose (object=0xa24260 [NMVpnConnection]) at nm-active-connection.c:904
#13 0x00007ffff4b24fec in g_object_unref (_object=0xa24260) at gobject.c:3137
#14 0x0000000000577636 in nm_vpn_service_stop_connections (service=0x8ff610 [NMVpnService], quitting=1, reason=NM_VPN_CONNECTION_STATE_REASON_SERVICE_STOPPED) at vpn-manager/nm-vpn-service.c:150
#15 0x0000000000576ea2 in dispose (object=0x921060 [NMVpnManager]) at vpn-manager/nm-vpn-manager.c:284
#16 0x00007ffff4b24fec in g_object_unref (_object=0x921060) at gobject.c:3137
#17 0x00000000004d0f05 in dispose (object=0x88a2b0 [NMManager]) at nm-manager.c:5061
#18 0x00007ffff4b24fec in g_object_unref (_object=0x88a2b0) at gobject.c:3137
#19 0x0000000000444e08 in _nm_singleton_instance_destroy () at NetworkManagerUtils.c:138
#20 0x00007ffff7de97b7 in _dl_fini () at dl-fini.c:252
#21 0x00007ffff4444778 in __run_exit_handlers (status=status@entry=0, listp=0x7ffff47d0618 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#22 0x00007ffff44447c5 in __GI_exit (status=status@entry=0) at exit.c:104
#23 0x0000000000445b80 in main (argc=1, argv=0x7fffffffdf08) at main.c:458
(gdb)
We already avoid loading duplicate plugins by checking find_plugin().
That iterates the plugins @list and checks for duplicate names.
Additionally, also reject duplicates based on the @plugins list.
Also, move the check for "keyfile" before, so that all explicit
checks for (statically) known names are early and together.
NM was calling nm_bus_manager_start_service() to claim its bus name
before it exported any of its objects, but this didn't matter under
dbus-glib, because no client connections would be accepted until the
main loop was started later on, by which point we would have exported
everything.
But with gdbus, method calls are initially received in the gdbus
worker thread, which means that clients would be able to connect right
away and then be told that the expected interfaces don't exist.
So move the nm_bus_manager_start_service() call to occur after
creating NMSettings and NMManager (and, indirectly, NMAgentManager).
This requires splitting out the slow parts of nm_settings_new() into a
new nm_settings_start(), so that we can create and export it first,
and then read the connections, etc afterward. (Likewise, there were
still a few potentially-slow bits in nm_manager_new() which are now
moved into nm_manager_start().)
Our gdbus generated types use the same names as their corresponding
"real" types, but with "NM" changed to "NMDBus".
Unfortunately, that means that introspection/nmdbus-manager.c (the
generated type for src/nm-manager.c) uses the same type name as the
entirely unrelated src/nm-dbus-manager.c.
Fix this by removing the "d" from src/nm-dbus-manager.c. (We could
rename the generated type instead, but then it becomes inconsistent
with all the other generated types, and we're already using it as
"NMDBusManager" in libnm/nm-manager.c.)
Move D-Bus export/unexport handling into NMExportedObject and remove
type-specific export/get_path methods (export paths are now specified
at the class level, and NMExportedObject handles the counters for all
exported types automatically).
Since all exportable objects now use the same get_path() method, we
can also add some helper methods to simplify get_property()
implementations for object-path and object-path-array properties.
