Just for consistency, make settings related stuff live under the
org.freedesktop.NetworkManager namespace, rather than its own
org.freedesktop.NetworkManagerSettings namespace. Renames are done for
DBus interface names, DBus object paths, and polkit actions.
Remove the org.freedesktop.NetworkManagerSystemSettings bus name and
have everybody talk to org.freedesktop.NetworkManager. Now that we have
a single settings service that's embedded in the main daemon, we don't
need separate names anymore.
NMSysconfigSettings inherited the "bus" property from NMSettingsService.
The property was originally created to allow us to specify what DBus
connection to use, which was important in the days of user settings
services. Now, however, the daemon is the only thing that has a settings
service, and so we can trim a bit of clutter by removing this property
and using NMDBusManager directly.
NMSettingsConnectionInterface was created to allow the daemon and NM
clients to have common code that handled both system and user
connections. It's no longer needed now that user settings services are
gone.
This concludes the flattening of libnm-glib.
The various "update" functions implemented by NMSysconfigConnection have
become confusing. Depending on how you count, we've wound up with about
4 functions that all share the name "update" but nonetheless do
different things. These functions used to be distributed over several
interfaces implemented by NMSysconfigConnection, but now that we've
removed NMExportedConnection and are about to remove
NMSettingsConnectionInterface, they will be all crammed into a single
interface and will be even more confusing than before. It's time to
give better names to these guys.
The renames planned are:
- nm_settings_connection_interface_update() -->
nm_sysconfig_connection_commit_changes()
- nm_sysconfig_connection_update() with signal_update==FALSE -->
nm_sysconfig_connection_replace_settings()
- nm_sysconfig_connection_update() with signal_update==TRUE -->
nm_sysconfig_connection_replace_and_commit()
This commit performs the last two renames. The first will be performed
when removing NMSettingsConnectionInterface.
We also have nm_sysconfig_connection_replace_and_commit() have an
async-ish API that accepts a callback. This fits nicely with the
async-ish API of nm_settings_connection_interface_update(), and it lets
us clean up pk_update_cb() a bit.
NMExportedConnection originally implemented its DBus method call
handlers as virtual functions, primarily so that system and user
settings services could implement them differently.
NMIfupdownConnection also depended on GetSecrets being virtual, so this
was retained when NMExportedConnection was flattened into
NMSysconfigConnection.
However, it turns out that NMIfupdownConnection doesn't really need
these functions to be virtual; it's more appropriate to override the
methods of NMSettingsConnectionInterface (which are used by the DBus
handlers). Indeed, we really don't want settings plugins to override
the DBus handlers, as we must authorize the caller before doing anything
else. So we can save a bunch of code and devirtualize these handlers.
ifupdown only supports secrets for wireless connections, so attempts to
get non-wireless secrets need to fail. Previously, this was accomplished
by overriding NMSysconfigSettingsClass->get_secrets, the handler for
DBus GetSecrets() method calls. This had some problems:
- It created an information leak. The first thing the
NMSysconfigConnection implementation does is verify that the caller is
authorized to get secrets information, but nm-ifupdown-connection ends
up performing its additional check before authorization happens. Thus,
unauthorized users are able to determine that some connections don't
have secrets. This will become more significant when secrets handling
is revamped.
- We'd really like to devirtualize these DBus method call handlers.
They were inherited from from NMRemoteConnection, where we needed
these functions to be virtual so that user and system settings
services could implement them differently. That is no longer needed.
ifupdown was the last place were we actually "needed" these functions
to be virtual.
With this commit, we fix these problems by overriding
nm_settings_connection_interface_get_secrets instead.
NMSettingsInterface was created to allow code to operate on a settings
service without caring about what kind of settings service it was. Now
that we have just one settings service, this is no longer needed.
More work needs to be done in order to handle errors and permission
settings in an appropriate manner.
In continuation of the theme, the removal of user settings services
means that the distinction between NMSysconfigConnection and
NMExportedConnection is no longer needed. Merge NMExportedConnection
into NMSysconfigConnection.
Much as with nm-remote-settings and nm-remote-settings-system, the
removal of user settings services means there is no more need for
separate interfaces for user and system settings services.
In libnm-glib, this commit merges everything in
nm-settings-system-interface into nm-settings-interface. Alongside with
that, we merge everything in the
org.freedesktop.NetworkManagerSettings.System DBus interface into
org.freedesktop.NetworkManagerSettings.
Originally, nm-remote-settings was used by the daemon to monitor the
user settings service, and its subclass nm-remote-settings-system was
used by NM clients to monitor the system settings service. With user
settings services gone, this distinction is no longer needed. Simplify
things a bit and merge the classes.
Now that we have only one settings service, there is no more need to
have common settings service code in libnm-glib. So we can simplify
things somewhat my moving everything from nm-settings-service into
nm-sysconfig-settings.
Remove code related to "connection scope" and such. Later, we will also
do lots of code flattening and simplification that's possible now that
user settings are gone.
Remove all support for user settings services from nmcli. Update its
manpage to reflect this.
Manpage edits also anticipate changes to be made in regards to how
secrets are managed.
Remove all references to connection scope and user-settings services
from the various internal APIs of the daemon. The external DBus API
remains unchanged, albeit in stub form for scope stuff.
It turns out that user settings services are strange and complicated
beasts. We will remove support for them, and we will later implement
security mechanisms on the system settings service that will do what
user settings services were intended to do.
This commit is a bulk removal of nm-manager's internal support code for
user settings services. The external API is largely unchanged, but
errors are returned if anyone ties to do something with user settings.
Work remaining includes some possible flattening of nm-manager's
internal code, along with code removal and API changes in other modules.
If the client was disabled with --with-dhclient=no or
--with-dhcpcd=no, then it's corresponding _PATH will be an empty
string. In that case we want to ignore that client completely
since it was disabled at build time.
Kind of a hack for now, would be better to push down a flag about
whether the update request came in from D-Bus, internally, or from
inotify, but that's a lot more invasive.
Treat them as unmanaged for now so that they dont' need NM_CONTROLLEd=no
which would require further configuration when NM does start to support
these configs.
NMIfupdownConnection really is a subclass of NMSysconfigConnection (as
declared via the G_DEFINE_TYPE macro in nm-ifconfig-connection.c), but
the header incorrectly used NMExportedConnection* in the class and
instance structs. We got away with it because NMSysconfigConnection*
didn't contain anything other than the stuff inherited from
NMExportedConnection*, but it would have caused much trouble if we did
add something.
